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objetivos 


Conceitos basicos de redes 






Apresentar os conhecimentos básicos para entender como as redes de computadores 






interagem, e como podem ser organizadas e interligadas para serem aproveitadas 





para prover os mais variados serviços. 







Introdução a redes de computadores, conceitos básicos e terminologia; interconexão 





de redes, equipamentos que a possibilitam, categorias e topologias de redes mais 
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usuais e meios de comunicação utilizados na maioria das redes. 








Redes de computadores 





Uma rede de computador é uma interconexão de estações de trabalho, periféricos, 


terminais e outros dispositivos. Características de uma rede: 
a Dois ou mais computadores interligados. 

o Meio físico de comunicação (hardware e software). 

a Aplicativos para transferência de informação. 


Existem diversas definições para uma rede de computadores. Segundo William Stallings, 
“quando dois ou mais computadores estão interconectados via uma rede de comunicação, 
o conjunto das estações de computadores é chamado de rede de computadores”. 


Já a organização internacional de padronização ISO define uma rede de computadores na 
norma ISO/IEC 7498-1: “Um conjunto de um ou mais computadores, o software associado, 
periféricos, terminais, operadores humanos, processos físicos, meios de transferência de 

informação, entre outros componentes, formando um conjunto autônomo capaz de exe- 

cutar o processamento e a transferência de informações”. 


Todas as definições têm algumas características em comum, a saber: 


a Dois ou mais computadores interligados; 

a Meio físico de comunicação (com fio, sem fio, metálico, fibra etc); 

a Vários tipos de equipamentos (estações de usuários, servidores, concentradores etc); 
a Software para comunicação entre os equipamentos (protocolos); 


ao Software de aplicação, para transferência de informação. 
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De maneira geral, podemos dizer que os componentes de uma rede são: 


mn Estações de trabalho de usuários, que podem ser de vários tipos: desktops, laptops, 
dispositivos móveis em geral: celulares, tablets etc; 


a Meios de comunicação de qualquer tipo para interconexão dos equipamentos de rede; 


oa Equipamentos de rede que compõem a infraestrutura da rede: hubs, switches, 
roteadores, etc. 


É importante ressaltar que a rede não é um fim em si mesmo, isto é, ninguém monta uma 
rede simplesmente para interligar equipamentos fisicamente, sem que haja algum tipo de 
transferência de informação. A motivação básica para a criação de redes é a transferência 


de informações entre os equipamentos que a compõem. 


Atransferéncia de informações pode ser feita de várias maneiras, dependendo das necessi- 
dades dos usuários, das aplicações desenvolvidas, dos protocolos de redes e da infraestrutura 
física propriamente dita da rede. 


Em resumo, podemos conceituar uma rede como uma interconexão de estações de 
trabalho, periféricos, terminais e outros dispositivos. 


Para que servem as redes? 


As redes fazem parte do nosso dia a dia, permitindo o acesso a partir de nossos celulares, 
tablets e notebooks, seja ela a rede da nossa organização ou os serviços da internet. Cabe 
a organização prover a infraestrutura de rede de acesso sobre a qual são disponibilizados 
os serviços e aplicações corporativas. 


As redes servem para: 


ao Permitir aos usuários acesso remoto a serviços e aplicações como: correio eletrônico, 
internet banking e comércio eletrônico, para citar os mais comuns. 


ao Permitir a comunicação entre os usários, como os serviços de voz sobre IP e video- 
conferência, entre tantos outros. 


a Compartilhar recursos especializados como impressoras, disco e processamento 
(exemplo: grids computacionais). 


Tipos de redes 


Mesmo com essas semelhanças, as redes podem ser divididas em duas categorias 
mais amplas: 


a Redes par-a-par. 


o Redes cliente-servidor. 








Figura 1.1 
Redes par-a-par e 
cliente-servidor. 


Grupo de trabalho 


Pelo termo 
subentende-se um 
pequeno grupo de 
pessoas. Uma rede 

par-a-par, tipicamente, 
tem pouco menos 
de 10 computadores. 


A distinção entre as redes par-a-par (peer-to-peer) e as redes cliente-servidor é importante, 
pois cada uma possui capacidades diferentes. O tipo de rede a ser implementada depende 


de características que incluem as relacionadas a seguir. 


Redes par-a-par 
a Cada computador funciona como cliente e servidor. a 
o Redes relativamente simples. 

o Nivel de suporte administrativo disponível. 

a Sem hierarquia. 

a Sem servidores dedicados. 

a Todos os computadores podem ser cliente e servidor. 

a Construídas com os serviços do sistema operacional. 

a Mais simples e baratas do que as redes cliente-servidor. 

o Também chamadas de grupos de trabalho. 

o Tipicamente têm menos de 10 computadores. 

a Todos os usuários estão localizados na mesma área geral. 


a Asegurança não é uma questão importante. 





o Aempresae a rede terão um crescimento limitado em um futuro previsível. 


Em uma rede par-a-par, não existem servidores dedicados ou hierarquia entre os computa- 
dores. Todos os computadores são iguais e, portanto, chamados pares. Normalmente, cada 
computador funciona tanto como cliente quanto como servidor, e nenhum deles é designado 
para ser um servidor para toda a rede. O usuário de qualquer computador determina os 
dados de seu computador que são compartilhados na rede. 


As redes par-a-par são relativamente simples. Uma vez que cada computador funciona 
como cliente e servidor, não há necessidade de um servidor central complexo ou de outros 
componentes para uma rede de grande capacidade. As redes par-a-par podem ser mais 


baratas do que as redes cliente-servidor. 


As redes par-a-par também são chamadas de grupos de trabalho. 


Em uma rede par-a-par, o software de comunicação de rede não requer o mesmo nível de 
desempenho e segurança de um software de comunicação de rede projetado para servi- 
dores dedicados. Os servidores dedicados funcionam apenas como servidores e não são 
utilizados como um cliente ou uma estação de trabalho. Eles serão discutidos com mais 
detalhes posteriormente. 


Em sistemas operacionais como Microsoft Windows, desde a versão 2000, bem como nos 
sistemas Unix/Linux, as redes par-a-par são construídas dentro do sistema operacional, 
sem a exigência de nenhum outro software para configurar uma rede deste tipo. Em um 
ambiente par-a-par típico, várias questões de rede possuem soluções de implementação 
padronizadas, que incluem: 


a Computadores localizados nas mesas dos usuários; 


a Usuários que atuam como seus próprios administradores e planejam sua própria segurança; 


o Utilização de um sistema simples de cabeamento de fácil visualização, que conecta 


computador a computador na rede. 
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As redes par-a-par são uma boa escolha para ambientes com as seguintes características: 


a Menos de 10 usuários; 
a Todos os usuários estão localizados na mesma área geral; 
a Aseguranca não é uma questão importante; 


o Aempresa e a rede terão um crescimento limitado em um futuro previsível. 


Requisitos do computador para rede par-a-par 


Em um ambiente par-a-par, cada computador deve: a 


o Utilizar uma porcentagem significativa de seus recursos para suportar o usuário local 


(o usuário no computador). 


o Utilizar recursos adicionais para suportar cada usuário remoto (o usuário que esta 


acessando o computador via a rede) que estiver acessando seus recursos. 


Em uma rede par-a-par, cada usuário administra seu próprio computador, uma vez que não 
existe servidor de rede e, portanto, também não há necessidade de administração centrali- 
zada, nem da figura do administrador de rede. Assim, cada usuário configura os recursos de 
seu computador que estarão disponíveis para os demais usuários da rede: discos, pastas, 
impressoras, entre outros, definindo se o acesso vai ser livre para todos ou mediante senha, 
e assim por diante. Então, parte dos recursos de seu computador será usada pelos demais 
membros da rede, e parte usada pelo próprio usuário. Essa proporção de utilização de 
recursos fica a critério de cada usuário. Usuários mais “conservadores” poderão liberar 
pouco ou nenhum recurso para a rede, enquanto usuários mais “liberais” poderão liberar 
mais recursos para a rede. 


Redes cliente-servidor 





a Servidores dedicados. 

o Estações clientes não oferecem serviços à rede. 

a Usadas em ambientes com mais de 10 usuários. 

Podem ser necessários vários servidores: 

a Servidores de Arquivo e Impressão. 

a Servidores de Aplicações. 

a Servidores de Correio. 

o Servidores de Fax. 

a Servidores de Comunicação. 

Em um ambiente com mais de 10 usuários, uma rede par-a-par, com os computadores 
operando como servidores e clientes, provavelmente não será adequada. Portanto, a maior 


parte das redes possui servidores dedicados. Um servidor dedicado é aquele que funciona 
apenas como servidor e não é utilizado como cliente ou estação de trabalho. 


Os servidores são “dedicados” porque são otimizados para processar rapidamente as 
requisições dos clientes da rede e para garantir a segurança dos arquivos e pastas. As redes 
baseadas em servidor tornaram-se o modelo padrão para a comunicação de rede e serão 
utilizadas como exemplos básicos. 
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Conforme aumentam o tamanho e o tráfego das redes, mais de um servidor é necessário 





na rede. Como a diversidade de tarefas que os servidores devem desempenhar é variada 


e complexa, a distribuição de tarefas entre vários servidores garante que cada tarefa seja 
desempenhada da maneira mais eficiente possível. Os servidores de grandes redes se tor- 


naram especializados para acomodar as necessidades crescentes dos usuários. 


Em uma rede típica baseada em servidor, os diferentes tipos de servidores incluem os que 


serão analisados a seguir. 
Servidores de arquivo e impressão 


Os servidores de arquivo e impressão gerenciam o acesso do usuário e a utilização dos 
recursos de arquivos e impressora. Por exemplo, se você estivesse executando um aplica- 
tivo de processamento de texto, o aplicativo seria executado no seu computador e o docu- 
mento seria armazenado no servidor de arquivos e impressão, mas transferido e carregado 
na memória de seu computador para que você possa utilizá-lo localmente. 


Servidores de aplicações 


Os servidores de aplicações executam as funções de servidor, disponibilizando dados para 
os clientes. Por exemplo, os servidores armazenam enorme quantidade de dados que estão 


estruturados para facilitar sua recuperação. 


Servidores de aplicações são diferentes de um servidor de arquivo e impressão, em que os 
dados ou o arquivo são carregados para o computador que fez a requisição. Com um ser- 
vidor de aplicação, o banco de dados fica no servidor e apenas os resultados requeridos são 


carregados no computador que fez a requisição. 


Uma aplicação cliente executada localmente tem acesso aos dados no servidor de aplicação. 
Em vez de todo o banco de dados ser carregado do servidor para o seu computador local, 


apenas os resultados da sua consulta são carregados nele. 

Servidores de correio 

Os servidores de correio gerenciam mensagens eletrônicas entre os usuários da rede. 
Servidores de fax 


Os servidores de fax gerenciam o tráfego de fax para dentro e para fora da rede, comparti- 
lhando uma ou mais placas de fax modem. 


Servidores de comunicação 


Os servidores de comunicação manipulam o fluxo de dados (por exemplo, arquivos, men- 
sagens, programas, etc.) entre a própria rede do servidor e outras redes, computadores 
mainframe ou usuários remotos, através da utilização de modems e linhas telefônicas para 


discar para o servidor. 


Vantagens da rede cliente-servidor 
a Compartilhamento de recursos. a 


a Compartilhamento de dados. 
ao Redundância. 
ao Escalabilidade. 


a Computador cliente mais simples. 
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Vantagens da rede cliente-servidor: 


oa Compartilhamento de recursos - um servidor é projetado para fornecer acesso a 
muitos arquivos e impressoras, ao mesmo tempo em que mantém o desempenho e a 
segurança para o usuário. 


o Compartilhamento de dados - o compartilhamento de dados baseado em servidor 
pode ser administrado e controlado de forma centralizada. Em geral, os recursos são 
centralizados e mais fáceis de localizar e suportar do que os recursos distribuídos em 
diversos computadores. 


o Redundância - através de sistemas de redundância, os dados em qualquer servidor 
podem ser duplicados e mantidos on-line para que, mesmo se algo acontecer aos dados 
na área de armazenamento de dados principal, uma cópia de backup dos dados possa ser 
usada para recuperá-los. 


o Escalabilidade - uma rede baseada em servidor pode dar suporte a milhares de usuá- 
rios, pois os utilitários de monitoração e gerenciamento de rede possibilitam a operação 
da rede para um grande número de usuários. Este tipo de rede jamais poderia ser geren- 
ciada como uma rede par-a-par. 


o Computador cliente mais simples - o hardware do computador cliente pode ser 
limitado às necessidades do usuário, pois os clientes não precisam de RAM adicional e 


armazenamento em disco para fornecer serviços do servidor. 


Tipos de conexões 


a Conexão ponto-a-ponto. 


a Conexão multiponto. 


L— 


Existem dois tipos básicos de conexão entre redes: ponto-a-ponto e multiponto; da combi- 
nação destas duas surgem as demais topologias que serão aqui abordadas. 


Conexão ponto-a-ponto 





a Conexão entre dois pontos. 

o Enlace dedicado. 

a Sem escalabilidade. 

Este é o tipo mais simples de ligação entre redes, em que os equipamentos são conectados 


entre si por uma única linha de comunicação. Quando algum deles tiver algo a transmitir, a 
linha estará disponível. 





it bs k n Figura 1.2 
Ba Rg Exemplo de conexão 
A B ponto-a-ponto. 


Esse tipo de conexão não é adequado para maior quantidade de equipamentos, como podemos 


ver na próxima figura, que reproduz as conexões ponto-a-ponto para 4 equipamentos. 


Figura 1.3 
Exemplo de mul- 
tiplas conexdes 
ponto-a-ponto. 


Figura 1.4 
Conexdo 
multiponto. 





Observe que são necessárias 6 linhas para interligar todos os equipamentos entre si. 


Q) O cálculo para “n” estações é feito através da fórmula: número de conexões = n(n-1)/2. 


No nosso exemplo, o número de conexões = 4(4-1)/2 = 6. Imagine agora o caso de uma 
centena ou mais de equipamentos interligados dessa forma; é o mesmo problema que os 
projetistas de redes telefônicas tiveram que resolver. Essa solução não tem escalabilidade. 
A solução adotada pelos projetistas de redes telefônicas foi uma das topologias clássicas 
que serão abordadas adiante neste curso. Antes disso, vamos apresentar outro tipo de 


conexão que não apresenta problemas de escalabilidade. 


Conexão multiponto 


a Muitos pontos ligados ao mesmo meio físico. 
a Mensagens propagadas por difusão. 


o Escalabilidade. 


Este tipo de conexão permite que todas as estações se comuniquem entre si diretamente, 
e não apresenta os problemas de escalabilidade da conexão ponto-a-ponto. Existe apenas 
um único meio de comunicação interligando todas as estações, através de muitos pontos 

de conexão, um para cada estação; daí o nome de multiponto. A principal característica de 


conexões multiponto é permitir a conexão de uma grande quantidade de estações. 






Ponto de 
conexão 


As topologias clássicas e suas derivadas são tipos especiais de redes que usam as caracterís- 


ticas dos dois tipos básicos (ponto-a-ponto e multiponto). 


Topologias de redes 


o Barramento. 
o Anel. 


o Estrela. 
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Atopologia é a forma de ligação dos equipamentos em uma rede. A topologia se refere ao 
nível físico e ao meio de conexão entre os dispositivos, sendo dependente do projeto de 
suas funções, da confiabilidade e do seu custo de manutenção. Ao se planejar uma rede, 
muitos fatores devem ser considerados. Um dos fatores mais importantes é o tipo de par- 
ticipação dos nós. Um nó pode ser fornecedor ou usuário de recursos, ou uma mescla de 
ambos os tipos. 


Topologia Barramento 


am 
a Conexões multiponto. 


o Mensagens propagadas por difusão. 

o Controle de acesso ao meio centralizado ou descentralizado. 
a Escalabilidade. 

a Limitada fisicamente pelo tamanho do barramento. 

a Boatolerância a falhas. 


Neste tipo de topologia todos os nós (estações) se ligam ao mesmo meio de transmissão. 
A barra é geralmente compartilhada em tempo e frequência, permitindo a transmissão de 
informações. O tráfego das informações é bidirecional e cada nó conectado à barra pode 
escutar todas as informações transmitidas. Esta característica facilita as aplicações que 
requerem a propagação das mensagens por difusão. 





Observe que essa topologia é uma simples aplicação do tipo básico multiponto, normalmente 
usada com cabeamento coaxial, que requer o uso de terminadores nas extremidades do 
barramento para casar a impedância e evitar a reflexão do sinal elétrico. O barramento pode 


ser um simples segmento de rede interligando as estações dos usuários ou um backbone 


que interliga diversos segmentos de rede. 


Existe uma variedade de mecanismos para o controle de acesso ao barramento, que podem 
ser centralizados ou descentralizados. A técnica adotada para acesso à rede é a multiplexação 
no tempo. No controle centralizado, o direito de acesso é determinado por uma estação 
especial da rede. Em um ambiente de controle descentralizado, a responsabilidade de 
acesso é distribuída entre todos os nós. 


Nas topologias em barramento, as falhas nas estações não causam a parada total do 
sistema, que no entanto pode ser causada por falhas no barramento. O desempenho de um 
sistema em barramento é determinado pelo meio de transmissão, número de nós conectados, 
controle de acesso e tipo de tráfego, entre outros fatores. O tempo de resposta pode ser 
altamente dependente do protocolo de acesso utilizado. 


Figura 1.5 
Topologia 
Barramento. 


Backbone 


A interconexão central 
de uma rede pode 

ser entendida como 
uma espinha dorsal de 
conexões que interliga 
pontos distribuídos da 
rede, formando uma 
grande via de tráfego 
de informações. 


Figura 1.6 
Topologia Anel. 


Topologia Anel 


a Conexões ponto-a-ponto. 

o Mensagens propagadas de uma estação para outra. 
o Controle de acesso ao meio deterministico. 

o Pouca tolerância a falhas. 


Uma rede em anel consiste de estações conectadas através de um caminho fechado. 

Nesta configuração, redes em anel são capazes de transmitir e receber dados em qualquer 
direção, mas as configurações mais usuais são unidirecionais, de forma a tornar menos 
sofisticados os protocolos de comunicação que asseguram a entrega da mensagem ao 
destino corretamente e em sequência. Observe que esta topologia nada mais é do que uma 


sucessão de conexões ponto-a-ponto entre as estações, de maneira a formar um anel. 





Quando uma mensagem é enviada por um nó, ela entra no anel e circula até ser retirada 
pelo nó destino, ou então até voltar ao nó fonte, dependendo do protocolo empregado. 

O último procedimento é mais desejável porque permite o envio simultâneo de um pacote 
para múltiplas estações. Outra vantagem é permitir que determinadas estações possam 
receber pacotes enviados por qualquer outra estação da rede, independentemente de 


qual seja o nó destino. 


Os maiores problemas desta topologia são relativos à sua baixa tolerância a falhas. Qual- 
quer controle de acesso empregado pode ser perdido por problemas de falha, podendo ser 
difícil determinar com certeza se este controle foi perdido ou decidir o nó que deve recriá-lo. 
Erros de transmissão e processamento podem fazer com que uma mensagem continue 
eternamente a circular no anel. A utilização de uma estação de monitoramento contorna 
estes problemas. Outras funções desta estação seriam: iniciar o anel, enviar pacotes de 
teste e diagnóstico e outras tarefas de manutenção. A estação monitora pode ser dedicada 
ou outra qualquer que assuma essas funções em algum momento. 


Esta configuração requer que cada nó seja capaz de remover seletivamente mensagens da 
rede ou passá-las adiante para o próximo nó. Nas redes unidirecionais, se uma linha entre 
dois nós cair, todo o sistema sairá do ar até que o problema seja resolvido. Se a rede for 


bidirecional, nenhum nó ficará inacessível, já que poderá ser atingido pelo outro lado. 
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Topologia Estrela 





a Conexões ponto-a-ponto. 

a Mensagens propagadas através do nó central. 

a Controle de acesso ao meio centralizado ou descentralizado. 
o Boatolerância a falhas. 

a O nó central é chamado de “barramento colapsado”. 

Neste tipo de rede, todos os usuários comunicam-se com um nó central, por onde são trans- 
mitidas todas as mensagens. Através do nó central, os usuários podem transmitir mensa- 


gens entre si. O nó central funciona como um comutador de mensagens para transmissão 
dos dados entre eles. 


Observe que essa topologia é também uma combinação de conexões ponto-a-ponto, só que 
todas as conexões convergem para o nó central. 


Figura 1.7 
Topologia Estrela. 





O arranjo em estrela é a melhor escolha se o padrão de comunicação da rede for de um 
conjunto de estações secundárias que se comunicam com o nó central. As situações onde isto é 
mais comum são aquelas em que o nó central está restrito às funções de comutação de 


mensagens. 


O nó central pode realizar outras funções além da comutação e processamento das mensagens. 
Por exemplo, pode compatibilizar a velocidade de comunicação entre o transmissor e o receptor. 
Se os dispositivos fonte e destino utilizarem diferentes protocolos, o nó central pode atuar como 


um conversor, permitindo a comunicação entre duas redes de fabricantes diferentes. 


No caso de ocorrer falha em uma estação ou no elo de ligação com o nó central, apenas 
esta estação ficará fora de operação. Entretanto, se uma falha ocorrer no nó central, todo o 
sistema poderá ficar fora do ar. A solução deste problema seria a redundância do nó central, 
mas isto acarretaria um aumento considerável dos custos. 


A expansão de uma rede deste tipo só pode ser feita até certo limite, imposto pelo nó 
central: em termos de capacidade de comutação, número de circuitos concorrentes que 
podem ser gerenciados e número de nós que podem ser servidos. O desempenho de uma 
rede em estrela depende da quantidade de tempo requerido pelo nó central para processar 
e encaminhar mensagens, e da carga de tráfego de mensagens, ou seja, o desempenho é 
limitado pela capacidade de processamento do nó central. A maioria dos sistemas de com- 
putação com funções de comunicação possui um software que implementa esta configu- 


ração que facilita o controle da rede. 


Figura 1.8 
Comparação entre 
topologias de rede. 


Topologia hibrida 


Combinação de duas 
ou mais topologias 
de qualquer tipo. 


Comparação entre topologias 


O quadro seguinte resume os pontos positivos e negativos de cada topologia descrita até aqui. 


Tipos de Pontos 
topologia positivos 


Topologia Estrela : o 


ig 
io 
Topologia Anel ; o 
(Token Ring) a 
Topologia : o 


Barramento 


Mais tolerante a falhas. 
Facilidade para instalar usuários. 
Monitoramento centralizado. 


Razoavelmente fácil de instalar. 


Requer menos cabos. 
Desempenho uniforme. 


Simples e fácil de instalar. 


a Requer menos cabos. 


Fácil de entender. 


Redes LAN, MAN e WAN 


am 
Uma rede de comunicação pode ser classificada segundo um ou mais critérios. Podemos 


classificar as redes de acordo com: 


a Topologia (barramento, anel, estrela, híbrida). 


a Meio físico (cobre, fibra óptica, micro-ondas, infravermelho). 


a Tecnologia de suporte (comutação de pacotes, comutação de circuitos, assíncronas, 


plesiócronas, síncronas etc). 


a Segundo o ambiente ao qual se destinam (redes de escritório, redes industriais, redes 


militares, redes de sensores etc). 


Pontos 
negativos 


: o Custo de instalação maior 


porque usa mais cabos. 


: a Se uma estação para, 


todas param. 


: o Os problemas são difíceis 


de isolar. 


: a Arede fica mais lenta em 


períodos de uso intenso. 


: a Os problemas são difíceis 


de isolar. 





No entanto, a classificação mais comum baseia-se na área geográfica ou organizacional e aí 


entram os termos que normalmente ouvimos: LAN, MAN, WAN, PAN etc. Vamos apresentar 


as definições mais comuns. 


LAN 


o Cabeamento em distâncias de até 10 km. 


a Alta taxa de transmissão (Mbps, Gbps). 


o Baixa taxa de erros. 


o Baixo custo de cabeamento. 


a Propriedade privada. 


ao Topologia básica (barramento, anel, estrela). 





Redes LAN (Local Area Networks) também são designadas como redes locais. Tipo de rede mais 


comum, uma vez que permite interligar computadores, servidores e outros equipamentos de 


rede em uma área geográfica limitada, como uma sala de aula, residência, escritório etc. 
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Características: Figura 1.9 
Redes LAN. 
a Cabeamento em distâncias de até 10 km, dependendo do tipo de cabo usado (par metálico, 


fibra óptica, sem fio etc); 


ao Alta taxa de transmissão (Mbps, Gbps), em função das curtas distâncias e do tipo de 


cabeamento que permite taxas elevadas de transmissão; 
a Baixa taxa de erros, uma consequência das curtas distâncias e da qualidade do cabeamento; 


a Baixo custo de cabeamento, em função das distâncias envolvidas, uma vez que o custo 
do cabeamento é diretamente proporcional à distância; 


a Propriedade privada, devido à facilidade de cabear pequenas distâncias, usualmente 


dentro das instalações de uma empresa ou de uma residência; 


a Topologia básica (barramento, anel ou estrela). 


MAN 


a Cabeamento em distâncias de até 100 km. 
o Alta taxa de transmissão (Mbps, Gbps). 

a Baixa taxa de erros. 

a Custo de cabeamento médio. 

a Propriedade privada ou pública. 


a Topologia em anel. 


Figura 1.10 
Redes MAN. 


Redes MAN (Metropolitan Area Networks) são redes de comunicação que cobrem uma área 
do tamanho de uma cidade ou bairro. Permitem a interligação de redes e equipamentos 


numa área metropolitana, como em locais situados em diversos pontos de uma cidade. 


LAN 








Metropolitan 
Area Network 


Características: 

a Cabeamento em distâncias de até 100 km, para cobrir um bairro, uma cidade pequena 
ou um campus universitário; 

ao Alta velocidade de transmissão (Mbps, Gbps), como no caso das LANs; 

a Baixa taxa de erros, como também ocorre com as LANS; 


a Custo de cabeamento médio, uma vez que as distâncias envolvidas são maiores do que 


numa rede local; 


a Propriedade privada ou pública, dependendo de quem construiu a rede; numa rede local 
sempre é a própria empresa, mas em uma rede MAN pode ser um serviço oferecido por 


terceiros, em função dos custos de infraestrutura; 
a Topologia em anel, mais econômica para as distâncias metropolitanas. 


As redes MANS atuais estão usando a tecnologia Ethernet de LANs, porque as fibras ópticas 
permitem alcançar distâncias maiores com alta taxa de transmissão (dezenas de Gbps) a um 
custo inferior ao das redes WANs nas mesmas condições. Essas redes são chamadas redes 
Metro Ethernet. 


Graças à facilidade de instalação de fibras ópticas e ao seu baixo custo, as redes estão 
alcançando distâncias cada vez maiores, fazendo com que a simples classificação em função 
da distância fique rapidamente ultrapassada. Para diferenciar as redes entre si, a tecnologia 
utilizada é mais importante do que a distância entre os enlaces. 


WAN 


a Cabeamento de longas distâncias (sem limite). 

o Baixa a alta taxa de transmissão (Kbps, Mbps, Gbps). 
a Taxa de erros maior do que nas LANs. 

ao Alto custo de cabeamento. 


a Propriedade pública. 
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Redes WAN (Wide Area Netwoks) permitem a interligação de redes locais, metropolitanas e 
equipamentos de rede, em uma grande área geográfica, como um país ou continente. 





Situação em outubro de 2012 


Boa Vista 


Macapá 






E- 10Gb/s 

m 3Gb/s 

= 1Gb/s 
36 Mb/s 
20 Mbps 








Perto Alegre 
Figura 1.11 
Redes WAN. 
Caracteristicas: 
a Cabeamento de longas distâncias (sem limite), devido à maior abrangência geográfica; B 
consulte a versão 
o Taxa de transmissão pode ser de baixa a alta (Kbps, Mbps, Gbps), em função dos dife- atual do mapa em 


rentes tipos de meios físicos adotados e das distâncias envolvidas; http://www. rnp.br/ 


no Taxa de erros superior a das LANs, em função do tipo de meio físico adotado e das 
distâncias envolvidas; 


ao Alto custo de cabeamento, por causa da abrangência geográfica; 


a Propriedade pública, devido ao alto custo dos investimentos em infraestrutura. 


As redes WAN projetadas para o serviço de dados têm velocidades muito altas, da ordem 
de Gigabits por segundo (Gbps), graças às facilidades de instalação de fibras ópticas e à 
redução do custo dos equipamentos de grande capacidade de transmissão. Tais redes se 
justificam pela velocidade de transferência de dados e pela possibilidade de compartilha- 
mento dos enlaces de alta velocidade entre muitos usuários. 


Desta forma, é possível encontrar WANs com velocidades muito altas (da ordem de dezenas 
de Gbps), superando as velocidades usuais de LANs (Mbps, Gbps). Normalmente essas WANs 
de velocidade muito alta são usadas nos backbones das operadoras de telecomunicações que 


prestam serviços de dados para o público em geral, normalmente usando a arquitetura TCP/IP. 


Meios de comunicacao 
Cabo metálico: 


o Cabo coaxial. 





a Cabo par trançado. 
Cabo fibra óptica. 
Cabeamento estruturado. 


Redes sem fio. 





O projeto de cabeamento de uma rede, que faz parte do meio físico usado para interligar 

computadores, é um fator de extrema importância para o bom desempenho de uma rede. 
Esse projeto envolve aspectos sobre a taxa de transmissão, largura de banda, facilidade de 
instalação, imunidade a ruídos, confiabilidade, custos de interfaces, exigências geográficas, 


conformidade com padrões internacionais e disponibilidade de componentes. 


Cabo metálico 


Cabo coaxial: 

o Cabo fino 10Base2 com conector BNC. 

a Cabo grosso 10Base5. 

a Obsoleto - substituído pelo par trançado e fibra óptica. 
Cabo par trançado: 

a Quatro pares trançados dois a dois. 

o Conector RJ-45 (8 fios). 

a Velocidades de 10 Mbps até 10 Gbps. 


a Facilidade de manutenção. 





Nessa categoria encontram-se atualmente dois tipos de cabos: coaxial e par trançado, sendo 
que o coaxial está praticamente fora de uso para redes locais, mas ainda é muito utilizado 


nas instalações de TV a cabo. 


Cabo coaxial 


a Velocidade de 10 Mbps. a 
a Distância maxima do segmento: 185m ou 500m. 


a Obsoleto, devido à dificuldade de manutenção. 


Os cabos coaxiais permitem que os dados sejam transmitidos através de uma distância maior 
que a permitida pelos cabos de par trançado sem blindagem (UTP), embora sejam mais caros 
e menos flexíveis que estes. O cabo coaxial foi o primeiro cabo disponível no mercado. Até 
alguns anos atrás era o meio de transmissão mais moderno que existia em termos de trans- 


porte de dados. Em redes locais são usados dois tipos de cabos coaxiais: 10Base5 e 10Base2. 


Os cabos 10Base2, também chamados de cabos coaxiais finos (ou cabos Thinnet) são os cabos 
coaxiais usados em redes Ethernet para a conexão de estações dos usuários. Seu diâmetro é 


de apenas 0.18 polegadas, cerca de 4.7 milímetros, o que os torna razoavelmente flexíveis. 


Segundo a norma IEEE802.3 de redes Ethernet, o comprimento máximo do cabo coaxial fino 
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é de 185m e as estações a ele conectadas constituem um “segmento Ethernet”. Podem ser 
necessários vários segmentos para conectar todas as estações de uma rede local, depen- 


dendo da quantidade de estações e das distâncias envolvidas. 


Os cabos 10Base5, também chamados de cabos coaxiais grossos (ou cabos Thicknet), 
possuem cerca de 0,4 polegadas ou quase 1 centímetro de diâmetro, e por isso são caros 
e difíceis de instalar, devido à baixa flexibilidade. Também podem ser usados vários seg- 
mentos para conectar todas as estações de uma rede local, dependendo da quantidade de 
estações e das distâncias envolvidas. É possível conectar segmentos 10Base2 e 10Base5, 
desde que atendendo à regra 5-4-3, alcançando distâncias entre 925m e 2500m. 


A regra 5-4-3 diz que uma rede Ethernet com cabo coaxial fino pode conter 5 segmentos 
unidos por 4 repetidores, mas somente 3 desses segmentos podem ser povoados por 
estações. Os outros dois segmentos restantes são usados como ligações entre repetidores. 
Repetidores podem ser usados para interligar segmentos Ethernet e estender a rede para 
um comprimento total de 925 metros até 2500 metros. A Figura 1.12 exemplifica essa regra. 










Trunk 
segment 1 


Repeater 1 


segment 2 


Trunk 
segment 3 


SEP Repeater 3 


Trunk 
> segment 4 
Trunk Repeater 4 Figura 1.12 
segment 5 Regra 5-4-3. 


Os cabos coaxiais sdo constituidos de 4 camadas: 


a Um condutor interno, o fio de cobre que transmite os dados; 
a Uma camada isolante de plástico, chamada de dielétrico, que envolve o cabo interno; 
o Uma malha de metal que protege as duas camadas internas e conduz o aterramento elétrico; 


o Uma nova camada de revestimento, chamada de jaqueta, conforme mostra a figura a seguir. 






















Fio de cobre 








Isolamento Figura 1.13 
Malha de metal interno Estrutura do 
Jaqueta (dielétrico) cabo coaxial. 


Para conectar as estações dos usuários ao cabo coaxial fino são usados conectores do tipo 
BNC, mostrados na figura a seguir. O “T” BNC é usado para conectar as estações ao cabo 
coaxial. O terminador é usado nas duas pontas do segmento do cabo coaxial para casa- 


mento de impedância e para eliminar a reflexão do sinal elétrico. 


Figura 1.14 
Conectores “T” BNC. 


Figura 1.15 
Cabo par trançado. 






Conector T 


Conector 
Terminador BNC 


O numero 10 na sigla 10Base2 significa que os cabos podem transmitir dados a uma veloci- 
dade de 10 Mbps; “Base” significa “banda base” e se refere ao tipo de transmissão digital com 
uma única frequência portadora, na qual somente uma estação transmite de cada vez, e o 
número 2, que teoricamente significaria 200 metros, na prática é apenas um arredondamento, 
pois nos cabos 10Base2 a distancia máxima utilizável é de 185 metros. O mesmo vale para o 


cabo 10Base5, com a diferença de que a distância máxima é de 500 metros. 


Cabo par trançado 


a Velocidade de 10 Mbps/10 Gbps. 
ao Topologia física estrela. 

a Topologia lógica barramento. 

a Exige concentrador. 


o Facilidade de manutenção. 


Os cabos par trançado são os mais usados, pois têm um melhor custo benefício. Podem ser 
comprados em lojas de informática, feitos sob medida ou ainda produzidos pelo próprio 
usuário, e ainda têm velocidade 10 vezes maior do que os cabos coaxiais, no mínimo. 


O cabo par trançado surgiu da necessidade de se ter cabos mais flexíveis e com maior veloci- 
dade de transmissão. Ele vem substituindo os cabos coaxiais desde o início da década de 90. 
Hoje em dia é rara a utilização de cabos coaxiais em novas instalações de rede, apesar do 

custo adicional decorrente da utilização de hubs ou switches. O custo do cabo é mais baixo e 


a instalação é mais simples. 


O nome “par trançado” não é exatamente a tradução do termo original (que seria “par 
torcido”, do inglês “twisted pair”). Os cabos coaxiais usam uma malha de metal que protege 
o cabo de dados contra interferências externas; os cabos de par trançado, por sua vez, usam 
um tipo de proteção mais sutil: o entrelaçamento dos cabos cria um campo eletromagnético 
que oferece uma razoável proteção contra interferências externas. Estes cabos são constitu- 
ídos justamente por 4 pares de cabos torcidos par-a-par, conforme mostra a figura a seguir. 


As chamadas “categorias” em sistemas de cabeamento em par trançado seguem padrões 
determinados e normatizados pela ANSI/EIA (American National Standards Institute/ 
Electronic Industries Alliance), que define diversas categorias (tipos de cabo, velocidades, 
junções, conectores etc) e seus usos. A tabela a seguir resume as categorias de cabos do tipo 
par trançado mais usadas e suas características. 
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Categoria 


CAT 1 


CAT 2 
CAT 3 
CAT 4 


CAT 5 


CAT 5E 


CAT 6 


CAT 6A 


CAT 7 


Taxa maxima de transmissão 


E Até 1 Mbps (1 MHZ) 


4 Mbps 

10/16 Mbps 
16/20 Mbps 
100 Mbps 

i 1 Gbps (4 pares) 


: 1 Gbps 
: (10 Gbps - protótipo) 


É Até 400 MHz 


É Até 625 MHz 
i (testado em campo até 500 MHz) : 


: 600-700 MHz 
: 1.2 GHz em pares com 
: conector Siemon 


Observações sobre a tabela: 


a As categorias 3 e 5 ainda são grande maioria das instalações existentes. 


Aplicação usual 


: Voz Analógico (POTS) 
: ISDN (Integrated Services Digital Network) Basic Rate Interface 
: Fiação tipo fio de telefone 


: Utilizado em sistemas de cabeamento IBM Token Ring 
; Voz e dados em rede 10BASE-T Ethernet 
: Usado em redes Token Ring de 16 Mbps 


į 100 Mbps TPDDI 
? 155 Mbps ATM 
: Não é mais utilizado, substituído pelo CAT 5E 


į 100 Mbps TPDDI 
į 155 Mbps ATM 
: Gigabit Ethernet 


; Aplicações de banda larga “super-rápidas” 


: Suporta completamente 10 Gigabit Ethernet (10GBASE-T) 


: Video em Full-motion 

? Telerradiologia 

: Redes especializadas de governo 

i: Redes especializadas de manufatura 
: Redes especializadas de ensino 

: Sistema blindado 


Figura 1.16 
Categorias de cabos 
par trançado. 


a Coma queda nos preços de equipamentos que suportam Gigabit Ethernet, os padrões 


CAT6 e CAT6A têm sido os preferidos para novas instalações, pois já oferecem suporte 


aos padrões Gigabit e 10 Gigabit Ethernet. 


A utilização do cabo par trançado tem suas vantagens e desvantagens. Veremos em seguida 


as principais. 


Vantagens 


o Preço - mesmo com a obrigação da utilização de outros equipamentos na rede, a 


relação custo benefício é melhor. 


o Flexibilidade - como é bastante flexível, ele pode ser facilmente passado por dentro 


de conduítes embutidos em paredes. 


o Facilidade de manutenção - cada estação é conectada ao concentrador com seu 


próprio cabo, de forma independente das demais estações. 


o Velocidade - atualmente esse cabo trabalha com taxas de transferência de 10 Mbps 


(categoria 3), 100 Mbps (categorias 5 e 5E), 1 Gbps (categorias 5 e 6) e de 10 Gbps 


(categorias 6 e 6A). 


Desvantagens 


m 
a Comprimento - sua principal desvantagem é o limite de comprimento do cabo, de 


aproximadamente 100m entre a estação e o concentrador. 


o Interferência - baixa imunidade à interferência eletromagnética, fator preocupante 


em ambientes industriais. 


Figura 1.17 
Estrutura do cabo 
de fibra óptica. 


A montagem do cabo par trançado é relativamente simples. Além do cabo, você precisará 
de um conector RJ-45 de pressão para cada extremidade do cabo e de um alicate de pressão 
para conectores RJ-45, também chamado de alicate crimpador. Assim como ocorre com o 
cabo coaxial, fica difícil passar o cabo por conduítes e por estruturas usadas para ocultar o 
cabo, depois que os conectores RJ-45 estão instalados. Por isso, o cabo deve ser passado 


antes da instalação dos conectores, sendo cortado no comprimento desejado. 


Lembre-se de deixar uma folga de alguns centímetros, já que o micro poderá posterior- 
mente precisar mudar de lugar. Além disso, você poderá errar na hora de instalar o conector 
RJ-45, fazendo com que seja preciso cortar alguns poucos centímetros do cabo para instalar 


novamente outro conector. 


Para a utilização de alguns poucos cabos, vale a pena comprá-los prontos. Já para quem vai 
precisar de muitos cabos, ou para quem vai trabalhar com instalação e manutenção de redes, 
é mais vantajoso ter os recursos necessários para construir os cabos. Devem ser comprados os 
conectores RJ-45, rolos de cabo, um alicate para fixação do conector e um testador de cabos. 


Vale a pena destacar que a montagem manual de uma rede de par trançado é viável em 
ambiente de uma LAN pequena ou rede doméstica. Em redes corporativas, é necessário uti- 
lizar ferramentas e equipamentos especiais de infraestrutura física, como será visto adiante 
quando tratarmos de cabeamento estruturado. 


Cabo fibra óptica 


a Velocidade 1 Gbps/10 Gbps/ 40 Gbps/100 Gbps. a 
a Conexões ponto-a-ponto. 

o Redes LAN e MAN Ethernet. 

o Imune a ruído eletromagnético. 


Ao contrário dos cabos coaxiais e de par trançado, que nada mais são do que fios de cobre 
que transportam sinais elétricos, a fibra óptica transmite luz e por isso é totalmente imune 
a qualquer tipo de interferência eletromagnética. Além disso, como os cabos são feitos de 
plástico e fibra de vidro (ao invés de metal), são resistentes à corrosão. 


O cabo de fibra óptica é formado por um núcleo extremamente fino de vidro, ou mesmo 

de um tipo especial de plástico. Uma nova cobertura de fibra de vidro, bem mais grossa, 
envolve e protege o núcleo. Em seguida há uma camada de plástico protetora cnamada de 
cladding, uma nova camada de isolamento e finalmente uma capa externa chamada bainha, 


conforme mostra a figura a seguir. 
























DO ë 
ee ee Cobertura Nucleo 
Cladding de fibra 


Isolamento 
Bainha 


A transmissão de dados por fibra óptica é realizada pelo envio de um sinal de luz codificado, 
dentro do domínio de frequência do espectro visível. As fontes de transmissão de luz podem 
ser diodos emissores de luz (LED) ou lasers semicondutores. O cabo óptico com transmissão 
de raio laser é o mais eficiente em potência, devido à sua espessura reduzida. Já os cabos 


com diodos emissores de luz são muito baratos, além de mais adaptáveis à temperatura 
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O Princípio de Propagação em Fibras Ópticas 


Gam Revestimento primário 


Revestimento Casca Núcleo 
primário 








O raio de luz com ângulo Ângulo de Ângulo de 
menor que o crítico é incidência reflexão 
absorvido pela casca A luz é propagada pela reflexão interna total 


Existem dois tipos de fibra óptica: monomodo e multimodo. A primeira é usada principal- 
mente em telecomunicações, devido às grandes distâncias que consegue alcançar. 

A segunda é usada em redes locais sem requisitos severos de distância, e são mais baratas 
do que as monomodo. A diferença entre elas está no modo de propagação da luz, conforme 


mostrado nas figuras a seguir. 


Casca 





Eixo 
Núcleo 
Casca 








Fibra Monomodo Casca 
Núcleo - entre 8 à 9 microns 
Casca - 125 microns 


Casca 








Eixo 
Núcleo 
Casca E 








4 Raio refratado 
Núcleo - 50 ou 62,5 microns 
Casca - 125 microns 


Apesar de alcançar distâncias muito maiores do que os cabos metálicos, a fibra óptica 
também sofre do fenômeno de atenuação do sinal luminoso, por causa da absorção de 

luz pela casca e imperfeições do material (sílica). Algumas frequências de luz sofrem mais 
atenuação do que outras. A figura a seguir mostra os comprimentos de onda mais usados e 


as atenuações máximas permitidas pela recomendação. 


Figura 1.18 
Princípio de pro- 
gação da luz em 
fibras ópticas. 


Figura 1.19 
Fibra óptica 
monomodo. 


Figura 1.20 
Fibra óptica multimodo 


Figura 1.21 
Comprimentos de 
onda mais usados 
em fibras ópticas. 


Figura 1.22 
Padrões de 
fibra óptica. 
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A fibra óptica tem inúmeras vantagens sobre os condutores de cobre, sendo as principais: 


a Maior alcance; 
o Maior velocidade; 


ao Imunidade a interferências eletromagnéticas. 


O custo do metro de cabo de fibra óptica não é elevado em comparação com os cabos 
convencionais. Entretanto, seus conectores são bastante caros, assim como a mão de obra 
necessária para a sua montagem. A montagem desses conectores requer, além de um curso 
especializado, o uso de instrumentos como microscópios, ferramentas especiais para corte 
e polimento, máquinas de fusão de fibra, medidores e outros aparelhos sofisticados. 


A Figura 1.22 mostra os principais padrões de fibra óptica. Os termos 051 e OS2 são classifica- 
ções de fibras ópticas monomodo, onde OS2 tem menor atenuação. Existem outros tipos de 
fibras especificadas no documento “Understanding OM1,0M2,0M3, 051,0S2 Fiber.pdf”. 





Padrão Taxa Comprimento 051 OS2 
de onda 

100BASE-SX 100Mb/s 850nm 

100BASE-FX 100Mb/s 1310nm 

100BASE-BX 100Mb/s 1310/1550nm 10-40Km 10-40Km 

100BASE-LX10 100Mb/s 1310nm 10Km 10Km 

1000BASE-SX 1Gb/s 850nm 

1000BASE-LX 1Gb/s 1310nm 5Km 5Km 

1000BASE-LX10 1Gb/s 850nm 10Km 10Km 

1000BASE-BX10 1Gb/s 1310/1490nm 10Km 10Km 

1000BASE-ZX : 1Gb/s 1550nm | 70Km 2 70Km 
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Padrão Taxa Comprimento OS1 0s2 








de onda 
1OGBASE-SR/SW 10Gb/s 850nm 
1OGBASE-LR/LW 10Gb/s 1310nm 2 4,2Km 10Km 
10GBASE-LRM 10Gb/s 1310nm 
10GBASE-LX4 10Gb/s 1310nm | 4,2Km 10Km 
10GBASE-ER/EW 10Gb/s 1550nm 8,9Km 22,25Km 
10GBASE-ZR/ZW 10Gb/s 1550nm 80Km 
40GBASE-SR4 40Gb/s 850nm 
40GBASE-LR4 40Gb/s 1310nm 4.7Km 10Km 
100GBASE-SR10 100Gb/s 850nm 
100GBASE-LR4 100Gb/s 1295/1310nm 8.3Km 10Km 
100GBASE-LR10 100Gb/s 1310nm 8.3Km 10Km 
100GBASE-ER4 100Gb/s 1295/1310nm | 16Km 40Km 


Cabeamento estruturado 


à 


a Norma ANSI/TIA/EIA-568-B. 

a Norma NBR 14565 ABNT 2001. 
a Cabeamento do prédio inteiro. 
a Patch panel. 


Montar uma rede doméstica é bem diferente de montar uma rede local de 100 pontos 
em uma empresa de médio porte. Não apenas porque o trabalho é mais complexo, mas 


também porque existem normas mais estritas a cumprir. 


O padrão para instalação de redes locais em prédios é o ANSI/TIA/EIA-568-B, que especifica 
normas para a instalação do cabeamento, topologia da rede e outros quesitos, chamados 
genericamente de cabeamento estruturado. No Brasil, temos a norma NBR 14565, publicada 
pela ABNT em 2001. 


A ideia central do cabeamento estruturado é cabear todo o prédio de forma a colocar pontos 
de rede em todos os locais onde eles possam ser necessários. Todos os cabos vão para um 
ponto central, onde ficam os switches e outros equipamentos de rede. Os pontos não pre- 
cisam ficar necessariamente ativados, mas a instalação fica pronta para quando precisar ser 
usada. A longo prazo, sai mais barato instalar todo o cabeamento de uma vez, de preferência 
antes do local ser ocupado, do que fazer modificações a cada vez que for preciso adicionar 
um novo ponto de rede. 


Além dos switches, um equipamento muito usado para a concentração dos cabos é o painel 
de conexão (patch panel), um intermediário entre as tomadas de parede e outros pontos de 
conexão e os switches da rede. Os cabos vindos dos pontos individuais são numerados e ins- 
talados em portas correspondentes do patch panel e as portas utilizadas são então ligadas 


aos switches. Veja o detalhe do patch panel na figura a seguir. 


Figura 1.23 
Patch panel. 





Além de melhorarem a organização dos cabos, os patch panels permitem o uso de um 
número muito maior de pontos de rede do que de portas nos switches. A ideia é que todo o 
escritório ou andar do prédio seja cabeado, com todas as tomadas ligadas ao patch panel. 
No caso de um escritório novo, provavelmente poucas tomadas serão usadas no início, per- 
mitindo o uso de um único switch. Conforme mais tomadas sejam usadas, são adicionados 
novos switches e outros componentes de rede, conforme a necessidade. Outra vantagem é 
que com os cabos concentrados no patch panel, tarefas como desativar um ponto ou ligá-lo 


a outro segmento da rede (ligando-o a outro switch ou roteador) ficam muito mais simples. 


Os patch panels são apenas suportes, sem componentes eletrônicos. Por isso são relati- 
vamente baratos, normalmente instalados em bastidores (racks), junto com os switches e 
outros equipamentos. Os switches são ligados às portas do patch panel através de cabos de 


rede curtos, cnamados de cabos de conexão (patch cords). 
Cabeamento horizontal 


Temos em seguida a rede secundária, que na norma internacional é cnamada de cabea- 
mento horizontal (horizontal cabling), sendo composta pelos cabos que ligam o armário de 
telecomunicações às tomadas onde são conectados os computadores da rede. Estes são os 
cabos permanentes, instalados como parte do cabeamento inicial e usados ainda por muito 


tempo. Veja a figura a seguir. 


Cabeamento 
secundário Pontos de rede 





Figura 1.24 

Cabeamento 

estruturado. 

Fonte: Morimoto, 

Carlos E. Redes, Guia 
Prático. GDH Press e Armário de 

Sul Editores, 2008 telecomunicações Área de trabalho 
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Como é possível notar, este sistema prevê o uso de três segmentos de cabo: 


a O patch cord ligando o switch ao patch panel; 
a O cabo da rede secundária, ligando o patch panel à tomada na área de trabalho; 


o O cabo entre a tomada e o computador. 
Cabeamento vertical 


O cabeamento vertical (ou backbone) provê a ligação dos armários de telecomunicações 
com a sala central de equipamentos, sendo constituído dos meios de transmissão, seus 
conectores e terminações. Para este subsistema é recomendado utilizar: 

o Fibra óptica multimodo de 62.5/125 microns; 

a Par trançado UTP de 100 Ohms; 

a Par trançado STP de 150 Ohms. 

Para outras aplicações são indicados os cabos: 

o Fibra óptica multimodo tipo 50/125 ou 100/140 microns; 

ao Fibra óptica monomodo; 


a Par trançado STP de 100 Ohms. 


Redes sem fio 


Rede sem fio é um conjunto de equipamentos de rede conectados por ondas eletromagné- 
ticas. O meio de comunicação é o ar, ao invés de fios. Uma rede sem fio dispensa cabeamento, 


tomadas, conectores, dutos, calhas etc. Também conhecida por WLAN (ou Wireless LAN). 
A motivação para o uso de rede sem fio pode ser: 


E 
a Mobilidade - WLANs permitem aos usuários o acesso à informação de qualquer lugar 
da organização, sem necessidade de procurar um ponto de rede para se conectar, 
aumentando a flexibilidade e a produtividade. 


ao Confiabilidade - menos fios e conectores significam menos pontos de falha e, 


portanto, menos problemas para usuários e gerentes de rede. 


o Facilidade de instalação - WLANs não precisam de caras e demoradas instalações 
de cabeamento, especialmente em áreas que não tenham sido construídas com a 
previsão de cabeamento estruturado; dispensam fios pendurados no forro ou nas 


paredes ou, ainda pior, espalhados pelo chão. 
a Custo -o custo da instalação de uma WLAN pode ser menor do que o de uma solução 


cabeada, principalmente em ambientes que sofrem frequentes mudanças de layout. 


o Escalabilidade - sistemas WLAN são facilmente configurados e remanejados para 
suportar uma variedade de ambientes de rede, tanto de pequenas como de 
grandes empresas. 


Componentes da WLAN 


o Estações de trabalho e dispositivos sem fio. 


o Pontos de acesso. | 


A Figura 1.21 representa uma rede sem fio típica, onde o roteador sem fio é o ponto central 


de conexão dos equipamentos que usam a interface de rede sem fio (wireless NIC). 


Figura 1.25 
Backbone WLAN. 


Esse roteador é chamado de Ponto de Acesso (Access Point). Os computadores e notebooks 
na figura representam as estações de trabalho dos usuários que requerem mobilidade e, 


portanto, não devem ser conectados a pontos fixos de rede, como ocorre com os desktops. 
WLAN de pequeno porte 
o Rede sem cabeamento. 


a Encontrada em casas e pequenas empresas. | 


Em instalações pequenas, podemos encontrar backbones WLAN sem rede cabeada, como 


na Figura 1.25. 


PC com NIC Notebook com NIC 
de rede sem fio de rede sem fio 





Roteador 
sem fio 





Notebook com NIC Notebook com NIC 
de rede sem fio de rede sem fio 


Esse tipo de instalação não é usual, principalmente no ambiente corporativo. Os usuários se 
conectam através de um ponto de acesso (access point), que atua como um switch ou rote- 
ador. Cada ponto de acesso pode conectar vários usuários, teoricamente não havendo limite 
de conexões. Na prática, o limite é a largura de banda disponível para os usuários. 


WLAN corporativa 
Integrada à rede cabeada da empresa. a 


A placa de rede sem fio é tratada pelo sistema operacional (Windows, Linux ou outro) como se 
fosse uma placa de rede Ethernet comum, simplificando assim a instalação e configuração. 

É mais comum a ocorrência de um misto de rede cabeada e WLAN, conforme mostrado na 
Figura 1.26. 
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PC com NIC 
de rede sem fio 


Roteador 
banda larga Modem ADSL 

















Me E > Switch Ethernet 





Roteador 
sem fio 


Figura 1.26 
Rede integrada LAN 
e WLAN. 


PCs com NIC par trançado 


O backbone da rede não exige mobilidade e pode ser cabeado, mesmo porque as exigén- 
cias de velocidade e capacidade podem exceder as especificações de uma WLAN. 

Os usuários, que exigem mobilidade, podem ser conectados via WLAN, integrando assim 
o melhor dos dois mundos. O ponto de acesso permite conexão à rede cabeada como se 


fosse um switch ou roteador. 


Padrões WLAN IEEE 802.11 


a 802.11b. 
a 802.11g. 
a 802.11a. 
a 802.11n. 


Todos os padrões mostrados operam com técnicas de transmissão específicas como, por 
exemplo, Direct Sequence Spread Spectrum - DSSS (Espalhamento Espectral por Sequência 
Direta), técnica desenvolvida para fins militares, com o objetivo de confundir a detecção de sinal 
por terceiros. O sinal resultante se assemelha a um ruído radioelétrico. A frequência de 2.4 GHz, 
embora tenha maior alcance do que a de 5.8 GHz, está mais sujeita a interferências de outros 


dispositivos como telefones sem fio, fornos de micro-ondas e controles remotos diversos. 


Devido à compatibilidade entre os padrões 802.11b e 802.11g, é comum encontrar notebooks e 
placas de rede sem fio que suportam os dois padrões. O padrão 802.11n é relativamente mais 
recente e os equipamentos que o suportam são mais caros e difíceis de encontrar. 


Figura 1.27 
Padrões WLAN 
IEEE 802.11. 





Figura 1.28 
Canais de trans- 
missdo WLAN. 


Interface 


Dispositivo fisico 
ou lógico que faz 
a adaptação entre 
dois sistemas. 


Padrão IEEE Frequência de Técnica de Velocidade 


operação modulação 
802.11b ! 2400-2483,5 MHz | DSSS É 11 Mbps 
802.11g : É DSSS, OFDM É 54 Mbps 
802.11a É 5150-5350 MHz : OFDM : 54 Mbps 


: 5470-5725 MHz 
| 5725-5850 MHz 


802.11n | 2400-2483,5MHz į MIMO-OFDM ! 600 Mbps 
? 5150-5350 MHz : 
| 5470-5725 MHz 
i 5725-5850 MHz 


Nos padrões 802.11b e 802.11, as frequências das portadoras variam de 2,401 a 2,473 GHz e 
são divididas em 11 canais sobrepostos, sendo ortogonais apenas os canais 1, 6 e 11, cada 
um com largura de banda de 22 MHz e banda de guarda (espaço entre os canais) de 3 MHz. 

A figura seguinte mostra essa distribuição de frequências pelos diversos canais. No caso de 
mais de um equipamento operando no mesmo local, é recomendável que cada equipa- 
mento utilize um canal ortogonal diferente dos demais, tanto quanto possível. Desta forma 


a interferência entre eles será mínima. 


Frequência (GHz) 


2,412 2,437 2,462 


Equipamentos de rede 


o Placas de rede. 
a Concentradores. 
a Switches. 

o Roteadores. 


Os equipamentos de rede são específicos para operar em rede, não fazendo parte do 
hardware padrão das estações de trabalho, em geral. Mesmo as interfaces de rede, que já 
vêm normalmente embutidas nos computadores IBM-PC e notebooks, são consideradas 
como periféricos opcionais pelo sistema operacional. Se não estiverem presentes, nenhuma 


funcionalidade da estação de trabalho será comprometida, exceto, é claro, o acesso à rede. 


A função principal desses equipamentos de redes é permitir o acesso à rede e o suporte da 
infraestrutura necessária para o bom funcionamento da rede. 


Placas de rede 


As interfaces de rede são fisicamente materializadas através das placas de rede, também 


conhecidas como NIC (Network Interface Card - Cartão de Interface de Rede). A placa de 


rede é o hardware que permite aos computadores conversarem entre si através da rede. 
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Sua função é controlar todo o envio e recebimento de dados através da rede. Além da arqui- 
tetura usada, as placas de rede à venda no mercado diferenciam-se também pela taxa de 


transmissão, cabos de rede suportados e barramento utilizado. 


Cada arquitetura de rede exige um tipo específico de placa de rede; você jamais poderá usar 
uma placa de rede Token Ring em uma rede Ethernet, pois ela simplesmente não conseguirá 
comunicar-se com as demais. As placas de rede mais usadas são as placas Ethernet. Elas 
adotam um esquema de endereçamento específico para identificar os computadores na 
rede local Ethernet, chamado de endereço MAC (MAC Address). 


ao Cada placa Ethernet tem um único endereço MAC. 


a Endereços MAC proveem uma forma dos computadores se identificarem, fornecendo um 
nome único e permanente. 


Os 3 primeiros octetos identificam o fabricante (OUI) e os 3 últimos a placa de rede propria- 


mente dita. O fabricante assume o compromisso de não repetir endereços. 
Endereços MAC 

a 
Gravados na memória ROM da placa de rede, identificam origem e destino do quadro 
Ethernet. Têm 48 bits expressos em hexadecimal: 
o 24 bits - OUI. 
o 24 bits - número serial. 
Endereços MAC são chamados às vezes de Burned-in Addresses (BIAS), porque são “quei- 
mados” na memória ROM da placa de rede e copiados na RAM quando a NIC inicializa. 
Possuem 48 bits em comprimento, expressos como 12 digitos em hexadecimal; os primeiros 
6 dígitos hexadecimais são administrados pelo IEEE e identificam o fabricante, sendo 


chamados de Organizational Unique Identifier (OUI); os 6 dígitos hexadecimais restantes 


traduzem o número serial da placa de rede. 


O protocolo Ethernet usa endereço MAC para identificar origem e destino do quadro 
Ethernet. Quando um computador envia um quadro Ethernet, ele inclui o endereço MAC na 
sua placa de rede (NIC) como o endereço MAC de origem. 


Analogia: como se, ao enviar uma carta, usássemos apenas um nome, ao invés de um ende- 
reço estruturado com CEP. 

Desvantagens dos endereços MAC: 

a Não identificam a rede, apenas o equipamento. 


a Não são estruturados hierarquicamente e são considerados “flat address space”. 


ao Devido a essa característica, não são roteáveis de uma rede para outra. 


Quadro Ethernet 


A figura a seguir mostra os campos do quadro Ethernet, destacando os campos de endereço. 


46-1500 4 


8 6 6 2 
destino origem Quadro Ethernet. 


Descrição dos campos: 


o Preambulo - sequência de 8 octetos com a finalidade específica de sincronizar os 
relógios (clock) do receptor com o do transmissor; os primeiros 7 octetos têm o mesmo 
conteúdo (em binário): 10101010 e o oitavo octeto (Start Field Delimiter) tem o seguinte 


conteúdo (em binário): 10101011; 


o Endereço destino - endereço MAC da estação de destino do quadro; quando o 
quadro se destina a todas as estações da rede local (broadcast) o endereço é (em hexa- 
decimal): ff: ff: ff: ff: ff: ff; 

o Endereço origem - endereço MAC da estação que enviou o quadro; 


o Tipo -indica o protocolo de camada de rede que está sendo encapsulado no quadro; os 
valores mais comuns nesse campo são (em hexadecimal): 0x8000 (protocolo IP - Internet 


Protocol) e 0x0806 (protocolo ARP - Address Resolution Protocol); 


ao Dados -campo que contém os dados recebidos da camada de rede, como por exemplo um 
datagrama IP; o tamanho mínimo desse campo é de 46 octetos e o máximo de 1500 octetos; 


o Frame Check Sequence (FCS) - campo de verificação de erros; se algum bit do quadro 
estiver corrompido, este campo indicará que o quadro está errado, mas não indicará o 
erro. Portanto, o quadro será descartado na impossibilidade de corrigi-lo. 


® 
Exercício de fixação iG 
Identificando as informações da interface de rede 


No prompt de comando do Windows, utilize o comando ipconfig /all e identifique as informa- 


ções da interface de rede do desktop da sala de aula. 

Descrição do adaptador físico: 

Endereço físico: 

Endereço IP: 

Máscara de rede: 

Gateway padrão: 

Faça a mesma consulta ao Linux da máquina virtual CORE disponibilizado no desktop. Para 


isto utilize o comando ifconfig. 


® Caso possua outro dispositivo com tecnologia wireless, como celular ou tablet, 


procure identificar estas informações no seu aparelho. 


Concentradores 


a Todos os dispositivos conectados ao concentrador estão no mesmo dominio 


de colisão. 
a Dispositivos compartilham banda sob demanda. 
Concentradores (hubs) são pontos de conexão para dispositivos em uma rede, que contêm 
múltiplas portas e são usados para conectar segmentos de uma LAN. Quando um pacote 
chega a uma porta, este é copiado para as outras portas; assim, todos os segmentos podem 
“ver” todos os pacotes. Um hub passivo simplesmente serve de conduto para os dados, 


habilitando-o a ir de um dispositivo (ou segmento) para outro. 
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Figura 1.30 
Analogia para 

o funcionamento 
de um hub. 












































A 


Todos os dispositivos conectados em um concentrador estão no mesmo domínio de colisão; 
o domínio de colisão é definido como um conjunto de equipamentos, em que apenas um 
pode transmitir de cada vez. Os equipamentos conectados a um hub, independente da 
quantidade de portas, estão todos no mesmo domínio de colisão. A banda disponível é 
dividida pelos dispositivos conectados. Enquanto A fala com B, C não pode falar com D: 

um único domínio de colisão. Por esse motivo, equipamentos do tipo hub não são recomen- 
dados nos dias de hoje. 


A Figura 1.30 compara concentradores (hubs) com uma autoestrada de uma única faixa 

de rolamento e com múltiplos pontos de acesso (entradas e saídas). Quanto mais pontos 
de entrada na autoestrada, maior a probabilidade de ocorrer uma colisão. Analogamente, 
quanto maior for o número de estações terminais (hosts) conectadas em um concentrador 


(hub) tentando acessar o meio físico, maior será a probabilidade de ocorrerem colisões. 


Switches 


a Cada segmento de rede tem seu próprio dominio de colisão. 

a Cada porta do switch é um dominio de colisão. 

a O switch é capaz de ler os endereços MAC de origem e destino. 

Para reduzir o número de colisões, um switch pode ser “dividido” em vários segmentos, 


cada um definindo um domínio de colisão distinto. Um switch de 24 portas possui 
24 domínios de colisão. 


Figura 1.31 
Esquema de 
operacdo de switch. 


Figura 1.32 
Analogia do 
funcionamento 
de switches. 


























Funcionamento do switch 


A grande vantagem do switch, em relação ao hub, decorre do fato do switch ser capaz de ler 
os endereços MAC de origem e destino no quadro Ethernet, enquanto o hub não lê os ende- 


reços MAC, apenas repete os quadros que entram por uma porta para todas as demais. 


Switch Ethernet é o equipamento que realiza a função de comutação de quadros na camada 
de enlace. Em redes Ethernet, os quadros da LAN são transferidos através da rede, com base 
nos endereços de origem e destino contidos no cabeçalho MAC do quadro. Essencialmente, 
é a mesma coisa que bridging, mas sempre empregando hardware dedicado para realizar a 


comutação (switching). 

















A Figura 1.32 compara um switch a uma autoestrada. Compare com a figura do concen- 
trador (hub), observando as diferenças e semelhanças. Note que a estrada tem várias faixas 


de rolamento, uma para cada domínio de colisão. 
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Roteadores 


Roteadores são dispositivos de rede mais tradicionais, como de backbone das intranets 
e da internet. Eles tomam decisões baseadas nos endereços de rede. Atualmente é 
comum que switches desempenhem funções de roteador. Principais funções: 


ao Seleção dos melhores caminhos de saída para os pacotes de entrada. 


a Roteamento destes pacotes para a interface de saída apropriada. 


Roteador é o dispositivo responsável pelo encaminhamento de pacotes de comunicação em 
uma rede ou entre redes. Tipicamente, uma instituição, ao se conectar à internet, deverá 
adquirir um roteador para conectar sua rede local (LAN) ao ponto de presença mais próximo. 


Roteadores escolhem os melhores caminhos através da construção de tabelas de roteamento 
e da troca de informações de rede com outros roteadores da rede. Esta troca, que pode ser 
realizada de várias formas e com diferentes algoritmos, caracteriza os protocolos de rotea- 
mento. Exemplos de protocolos de roteamento: RIPv1, RIPv2, OSPF, EIGRP, BGP, IS-IS. 


Um exemplo simples de roteador é o roteador sem fio usado em instalações de pequeno 
porte, também conhecido como roteador doméstico, que tem uma porta WAN (que se 
conecta à internet através de um provedor) e uma porta LAN para conectar a rede local do 
usuário. Essa rede local do usuário pode ser sem fio, através de adaptadores de redes sem 
fio (NIC ou adaptadores USB) ou com fio, conectada através do switch embutido no próprio 


roteador (usualmente com 4 portas LAN). 


Figura 1.33 
Escolha do melhor 
caminho pelo 
roteador. 





É possível configurar manualmente (estaticamente) tabelas de roteamento, mas em geral 
elas são mantidas e atualizadas dinamicamente pelos protocolos de roteamento, que 
trocam informações sobre a topologia de rede com outros roteadores vizinhos. O estudo 


avançado de protocolos de roteamento não faz parte do programa deste curso. 


Roteadores mantêm tabelas de roteamento construídas a partir da troca de informações 
entre roteadores vizinhos. Antes de qualquer roteamento, o administrador deve confi- 
gurar o roteador para adquirir, estática ou dinamicamente, informações que popularão 
sua tabela de roteamento. 


Funções dos roteadores: 


a Determinação do melhor caminho; 
ao Endereçamento lógico; 


a Conexão com serviços WAN. 


Um tipo comum de roteador é o ponto de acesso sem fio. 
Tabelas de roteamento 


a Endereçamento lógico permite hierarquização das redes. 
a Requer configuração: não é “plug and play”. 


a Usa informação configurada para identificar os melhores caminhos. 


Rede 1.0 Rede 4.0 








Figura 1.34 
Tabelas de 
roteamento. 






Rede 2.0 


Tabela de roteamento Tabela de roteamento 


| NeT | NT | 
1 1 SO 1 
2 2 so 0 
4 4 EO 0 


As tabelas de roteamento da figura anterior mostram o caminho para chegar às redes. Cada 
interface do roteador fica numa rede diferente. As interfaces conectadas as LANs são 
chamadas EO, E1 ..., enquanto as conectadas as WANs são chamadas SO, S1 etc. A métrica 
fornece uma ideia da distância até a rede, isto é, da quantidade de roteadores no caminho 
até o destino. Essa métrica é cnamada de “Vetor Distância” e mede a quantidade de saltos 


(hops) até o destino final. 


Veremos mais adiante que o endereçamento lógico em redes TCP/IP usa o endereço IP 

no formato de notação decimal pontuada como, por exemplo, 200.130.26.201, onde cada 
número representa um octeto, totalizando 4 octetos ou 32 bits. O esquema de endereça- 
mento IP adota uma abordagem hierárquica que identifica a rede e a estação dentro da 
rede, utilizando a máscara de rede para separar a identificação da rede da identificação da 
estação. A máscara de rede também adota o formato de notação decimal pontuada, tendo 
bits 1 no identificar de rede e bits O no identificador de estação. Por exemplo, a máscara 
255.255.255.0 indica que o identificador de rede possui 24 bits e o identificador de estação 
possui 8 bits. Veremos também que o roteador que encaminha pacotes para outras redes é 


denominado gateway padrão, sendo também identificado com um endereço IP. 
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Figura 1.35 
Portas LAN 
do switch. 


=F Roteiro de Atividades 1 


Atividade 1.1 - Montagem de uma rede par-a-par 


Cada bancada montará uma rede local par-a-par utilizando um switch do tipo mostrado na 


figura seguinte. O modelo pode variar de um fabricante para outro, mas o importante são 


as 8 portas LAN mostradas na figura. As bancadas serão respectivamente denominadas: 


grupo, grupo2, ..., grupo6 (máximo de 6 grupos). 





Q) TODOS os equipamentos devem estar DESLIGADOS durante a montagem da rede. 


1. O primeiro passo é desconectar as máquinas da bancada da rede local do laboratório 


e conectá-las às portas LAN do switch, em qualquer ordem. Use os cabos par trançado 


fornecidos pelo instrutor. 


2. Depois de conferir todas as conexões, ligue todos os equipamentos. Observe se os led's 


do switch que correspondem às portas LAN utilizadas estão acesos. Isso significa que o 


cabo está corretamente conectado. 


3. A configuração dos endereços IPv4 deve ser feita manualmente. 


O endereço IP que será usado deve ser escolhido da tabela abaixo, de acordo com o grupo 


ao qual sua bancada pertence. A máscara de sub-rede será sempre 255.255.255.0 e 0 


gateway padrão será sempre 192.168.1.254. 


Nome do grupo 


grupo1 


grupo2 


grupo3 


Faixa de endereços IPv4 


: 192.168.1.1 a 192.168.1.10 


: 192.168.1.11 a 192.168.1.20 


: 192.168.1.21 a 192.168.1.30 


> DDD» 


PDPPP 


Endereço por aluno (Windows e Linux) 
uno1: 192.168.1.1 e 192.168.1.2 
uno2: 192.168.1.3 e 192.168.1.4 


uno4: 192.168.1.7 e 192.168.1.8 
uno5: 192.168.1.9 e 192.168.1.10 


A 
A 
É Aluno3: 192.168.1.5 e 192.168.1.6 
A 

A 


uno1: 192.168.1.11 e 192.168.1.12 
uno2: 192.168.1.13 e 192.168.1.14 
uno3: 192.168.1.15 e 192.168.1.16 
uno4: 192.168.1.17 e 192.168.1.18 
uno5: 192.168.1.19 e 192.168.1.20 


uno1: 192.168.1.21 e 192.168.1.22 
uno2: 192.168.1.23 e 192.168.1.24 
uno3: 192.168.1.25 e 192.168.1.26 
uno4: 192.168.1.27 e 192.168.1.28 
unod: 192.168.1.29 e 192.168.1.30 
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Nome do grupo Faixa de endereços IPv4 Endereço por aluno (Windows e Linux) 


grupo4 : 192.168.1.31 a 192.168.1.40 : Aluno1: 192.168.1.31 e 192.168.1.32 
; i Aluno2: 192.168.1.33 e 192.168.1.34 

: Aluno3: 192.168.1.35 e 192.168.1.36 

i Aluno4: 192.168.1.37 e 192.168.1.38 

: Aluno5: 192.168.1.39 e 192.168.1.40 


grupo5 | 192.168.1.41 a 192.168.1.50 È Aluno1: 192.168.1.41 e 192.168.1.42 
; É Aluno2: 192.168.1.43 e 192.168.1.44 

É Aluno3: 192.168.1.45 e 192.168.1.46 

: Aluno4: 192.168.1.47 e 192.168.1.48 

É Aluno5: 192.168.1.49 e 192.168.1.50 


grupo6 : 192.168.1.51 a 192.168.1.60 : Alunot: 192.168.1.51 e 192.168.1.52 
; Aluno2: 192.168.1.53 e 192.168.1.54 

: Aluno3: 192.168.1.55 e 192.168.1.56 

: Aluno4: 192.168.1.57 e 192.168.1.58 

: Aluno5: 192.168.1.59 e 192.168.1.60 


4. Verifique no Windows ou no Linux se a configuração do endereço IP foi realizada com sucesso. 


Verifique no Painel de Controle do Windows se o firewall está desabilitado. Esse 
passo é importante, porque se o firewall estiver ativo, os testes de conectividade 
serão prejudicados. 


5. Teste a conectividade com as máquinas do seu grupo que estão ligadas ao switch de sua 
bancada, com o comando ping. 


No exemplo a seguir, assumindo que o endereço IP: 192.168.1.2 pertence à sua bancada. 
C:\>ping 192.168.1.2 

Disparando contra 192.168.1.2 com 32 bytes de dados: 

Respositalde LIZ lose nz: pyves="2  tempos=lns 28 

Resposta de 192.168.1.2: bytes=32 tempo=l6ms TTL=128 


Resposta de 192.168.1.2: bytes=32 tempo<ims TTL=128 








Resposta de 192.168.1.2: bytes=32 tempo=l6ms TTL=128 
ESUELISLICAS GO Ping para 102-108- l.2s 


Pacotes: Enviados = 4, Recebidos = 4, Perdidos = 0 (0% de 
perda), 





Aproximar um número redondo de vezes em milissegundos: 
Mínimo = Oms. Máximo = 16ms, Média = Sms 


Como podemos verificar, o ping funcionou, indicando que existe conectividade entre as 
máquinas de sua bancada. 


6. Teste a conectividade com as máquinas de outro grupo que estão ligadas ao switch de 
outra bancada, com o comando ping, conforme exemplificado a seguir, assumindo que 
o endereço IP: 192.168.1.11 pertence à outra bancada. Aguarde até que a outra bancada 
esteja com a configuração pronta. O resultado deve ser parecido com a listagem a seguir. 


Figura 1.36 
Rede local 
par-a-par. 


(Ce Nino) 192.166.11.1 

Disparando contra 192.168.11.1 com 32 bytes de dados: 
Esgotado o tempo limite do pedido. 

Esgotado o tempo limite do pedido. 


Esgotado o tempo limite do pedido. 





Esgotado o tempo limite do pedido. 











Estatísticas do Ping para 192.168.11.1: 





Pacotes: Enviados = 4, Recebidos = 0, Perdidos = 4 (100% de perda), 


Como podemos verificar, o ping NÃO funcionou, indicando que não existe conectividade 
com as máquinas das outras bancadas. Por quê? 








Atividade 1.2 - Conectando a rede ao switch do laboratório 


Nesta atividade conectaremos a rede do grupo à rede do laboratório, formando uma única 
rede na sala de aula. 


1. Conecte uma porta LAN do switch num ponto de rede do laboratório. Aproveite o ponto 


livre de uma das máquinas da bancada. A ligação deve ficar semelhante à mostrada na 


figura seguinte. 

















Rede local 
do laboratório 






































= me (mm) (mm 
A B c D 





Bancada 


Aguarde até que todas as demais bancadas façam o mesmo. O instrutor deve coordenar 


essa atividade. Repita o teste de conectividade entre os grupos. 


Atividade 1.3 — Teste de conectividade do grupo com a internet 


Para conexão com a internet, será necessário configurar o endereço do “Servidor DNS prefe- 


rencial” com o endereço IP fornecido pelo instrutor. 


O servidor DNS, também chamado de servidor de nomes, traduz os nomes dos equipa- 
mentos em endereços IP, para que os usuários não precisem decorar os endereços dos 
servidores que pretendem acessar. Por exemplo, é mais fácil decorar www.google.com do 
que o endereço IP: 74.125.234.112. 
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1. Verifique a conectividade com a internet, através do mesmo comando ping, conforme 
abaixo (podem ser escolhidos outros endereços na internet). 


C:\>ping esr.rnp.br 
Disparando contra esr.rnp.br [200.130.35.73] com 32 bytes de dados: 


Resposta de 200.130.35.73: bytes=32 tempo=23ms TTl=61 


N 


Resposta de 200.130.35.73: bytes=32 tempo=ims TTl=61 


Resposta de 200.130.35.73: bytes=32 tempo=lms TTl=61 





Resposta de 200.130.35.73: bytes=32 tempo=lms TTl=61 





Estatísticas do Ping para 200.130.35.73: 


Pacotes: Enviados = 4, Recebidos = 4, Perdidos = 0 (0% de 
perda), 


Aproximar um número redondo de vezes em milissegundos: 


Mínimo = Ims, Máximo = 23ms, Média = 6ms 


2. Observe que usamos o nome no lugar do endereço IP, mas mesmo assim funcionou. Por quê? 








Atividade 1.4 - Análise da troca de pacotes na rede 


Nesta atividade, usaremos o software Wireshark, que pode ser obtido gratuitamente em: 
http://www.wireshark.org 


O software pertence a uma categoria específica de ferramentas de rede chamada Network 
Protocol Analyzer (Analisador de Protocolo de Rede ou sniffer). O Wireshark captura pacotes 


IP na interface de rede do equipamento onde está sendo executado. Se o equipamento tiver 


várias interfaces de rede, é necessário especificar em QUAL interface de rede será realizada 


a captura de pacotes IP. 


1. Atela inicial do Wireshark está mostrada a seguir, na qual aparece como é feita a escolha 


Figura 1.37 
da interface de rede para iniciar a captura, bastando clicar no primeiro ícone à esquerda Tela inicial do 
na barra de ferramentas superior. Wireshark. 





~ the Wireshark Network Analyzer aAA 


ble tdt wew Go Capture Analyze Statistics Help 
Faga SALZA H o TF2 Raan aanak B 


per tthe avalable capture meerPaces, pj M a E Clara lia 


™ Wireshark: Capture Interfaces 





Description Packets Packets! 
= Adapter For generic dialup and YPN capture 
= Broadcom Netxtreme Gigabit Ethernet Driver (Microsoft's Packet Schedulor) 192,168.1.101 


@ VMware Virtual Ethernet Adapter 192.160.10.1 


E Weare Virtual EUnet Adopter 192,166.25,1 


Help 





No nosso caso, foi escolhida a interface de rede com o endereço IP: 192.168.1.101. Para isso, 
basta clicar no botão “Start” da interface escolhida. As demais são interfaces virtuais para 


outras finalidades que não se aplicam aqui. 


2. Vamos agora repetir o teste de conectividade entre as estações, usando a mesma janela 
DOS. O resultado apresentado a seguir corresponde a um ping da estação com endereço 
IP 192.168.1.101 para a estação com endereço IP: 192.168.1.102. 











GENS pino Wate). Ih Moe 

Disparando contra 192.168.1.102 com 32 bytes de dados: 
Resposta de 192.168.1.102: bytes=32 tempo=/ms TTL=128 
Resposta de 192.168.1.102: bytes=32 tembo lims TTl=128 
Resposta de 192.168.1.102: bytes=32 tempo<lms TTL=128 
Resposta de 192.168.1.102: bytes=32 tempo<lms TIL=128 
Estatisticas do Ping para 192.168.1.102: 





Pacotes: Enviados = 4, Recebidos = 4, Perdidos = 0 (0% de perda), 
Aproximar um número redondo de vezes em milissegundos: 


Mínimo = Oms, Máximo = 7ms, Média = lms 
Figura 1.38 


Janela de captura do 
Wireshark aberta na 
estação de origem 
do ping. 


Na janela de captura do Wireshark aberta na estação de origem do ping, podemos ver o 
resultado mostrado a seguir. Esse resultado varia de acordo com o instante em que o 
comando ping é executado. 


E Broadcom NetXtreme Gigabit Ethernet Driver (Microsoft's Packet Scheduler) : Capturing - Wireshark 


File Edit Yiew Go Capture Analyze Statistics Help 
Kee BAXA aF aaan amama] 
Filter: [icmp v Expression... Clear Apply 


Source 







Destination Protocol 






44 4.412176 . 168.1. 101 92. LOS, L. LUZ request 

45 144.419466 192.168.1.102 192.168.1.101 ICMP Echo Cping) reply 

46 145.415546 192.168.1.101 192.168.1.102 ICMP Echo (ping) request 

47 145.416184 192,.168.1.102 192.168.1.101 ICMP Echo (ping) reply 

48 146.415498 192.168.1.101 192.168.1.102 ICMP Echo Cping) request 

49 146.416102 192.168.1.102 192.168.1.101 ICMP Echo Cping) reply 

51 147.415441 192.168.1.101 192.168.1.102 ICMP Echo Cping) request 

52 147.415994 192.168.1.102 192.168.1.101 ICMP Echo (ping) reply v 





E | 


E E 


Frame 44 (74 bytes on wire, 74 bytes captured) 

Ethernet II, src: Dell eo:cc:c? (00:18:8b:e0:cc:c7), Dst: Dell e0:cc:57 (€00:18:8b:e0:cc:57) 
Internet Protocol, src: 192.168.1.101 (192.168.1.101), Dst: 192.168.1.102 (192.168.1.102) 
Internet Control Message Protocol 


É importante observar os seguintes pontos: 


o Na janela “Filter:”, foi digitado o nome do protocolo que desejamos analisar: ICMP. Só 
serão mostrados os pacotes desse protocolo, embora tenham sido capturados pacotes 
com todo tipo de protocolo; 


a O pacote 44, cujo endereço IP de origem é 192.168.1.101 e que tem como endereço IP de 
destino 192.168.1.102, é o pacote gerado pela aplicação ping que usa o protocolo ICMP, 
mensagem Echo request; 


a O pacote 45 é a resposta do destino (mensagem Echo reply); observe que na janela DOS 
mostrada antes só aparecem as respostas, que é o que interessa como resultado do 


teste de conectividade; 
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a Os demais pacotes são mera repetição dos pacotes acima (3 repetições). 


3. Fazendo o mesmo teste no sentido inverso (do endereço IP: 192.168.1.102 para o ende- 


reço IP: 192.168.1.101), obtemos o resultado na janela do Wireshark mostrado a seguir. 






T Broadcom NetXtreme Gigabit Ethernet Driver (Microsoft's Packet Scheduler) : Capturing - Wireshark 
File Edit Analyze 


Ena BALZA KeoaF2/SFB'QQQH\FUBXK |B 
Filter: a EEE v Expression... Clear Apply 


Destination 














View Go Capture Statistics Help 












Protocol Info 





s x 








OS. 

























903/12 1.102 92.16 ) request 

. 903735 elon 192.168.1. ICMP i reply 

. 897564 A .1.102 192.168.1.101 ICMP i request 
93 261.897582 192.168.1.101 192.168.1.102 ICMP reply 
94 262.897665 192.168.1.102 192.168.1.101 ICMP request 
95 262.897688 192.168.1.101 192.168.1.102 ICMP reply 
96 263.897634 192.168.1.102 152.168.1.101 ICMP Echo request 
97 263.897658 192.168.1.101 192.168.1 






- 102 ICMP Echo (ping) reply 





&) 


Frame 77 (74 bytes on wire, 74 bytes captured) 

Ethernet II, src: Dell e0:cc:57 (00:18:8b:e0:cc:57), Dst: Dell eO:cc:c7 (00:18:8b:e0:cc:c7) 
| Internet Protocol, src: 192.168.1.102 (192.168.1.102), Dst: 192.168.1.101 (192.168.1.101) 
Œ Internet Control Message Protocol 


& E 


Observe que agora os papéis se inverteram: é o endereço IP: 192.168.1.102 que origina os Figura 1.39 


pings (Echo request) e o endereço IP: 192.168.1.101 é quem responde (Echo reply). Janela do Wireshark 
com resultado do 


teste em sentido 


4. Os testes acima foram feitos apenas entre as estações com endereços IP: 192.168.1.101 nyers 


e 192.168.1.102. As demais estações da rede da nossa bancada, mesmo com o Wireshark 
ativado, não capturaram nenhum pacote com esse tipo de mensagem ICMP. Por quê? 


Caso não consiga responder, peça ajuda. 

















5. Para confirmar os resultados obtidos, repita os mesmos comandos nas outras estações 
da mesma rede e observe que agora são as estações inicialmente usadas que não cap- 
turam os pings. 


Atividade 1.5 - Montagem de uma rede sem fio ponto-a-ponto 


Nesta atividade serão usados os seguintes equipamentos: 


o 2APs; 

a 2 cabos par trançado pino a pino de 3m cada; 

o 1 adaptador USB de rede sem fio para cada computador. 

Serão formados 3 grupos de trabalho, um para cada AP. A razão disso é que serão usados 


3 canais de redes sem fio: 1, 6 e 11. Não serão usados mais canais, para evitar a interferência 


entre eles, uma vez que todos os APs estão na mesma sala. 


Antena 








Figura 1.40 
Roteador sem fio 
usado como AP. Portas LAN Porta Energia Reset 
Fonte: D-Link. WAN 
Nesta atividade será usada a rede sem fio (antena) e uma porta LAN para configuração do AP. 
Q) TODOS os equipamentos devem estar DESLIGADOS durante a montagem da rede. 
1. O primeiro passo é desconectar uma das máquinas da bancada da rede local do labora- 
tório e conectá-la à porta LAN do switch (qualquer porta). Use o cabo par trançado. 
2. Em seguida conecte a porta WAN do AP no ponto de rede do laboratório, aproveitando 
o ponto livre da máquina da bancada. A ligação deve ficar semelhante à mostrada na 
próxima figura. 
Figura 1.41 
Esquema de ligação 
da rede sem fio. A 


3. Depois de conferir todas as conexões, ligue todos os equipamentos. 
4. Após dar boot no Windows XP, execute o navegador e digite na janela de endereços: 


192.168.1.1 - endereço padrão de administração do roteador (verifique com o instrutor se é esse 


mesmo). Deverá surgir uma tela solicitando os dados de autenticação para acesso ao sistema. 


5. Digite o nome do usuário e a senha (confirme com o instrutor) e clique em OK. 


6. Deverá surgir a tela de configuração do roteador. Localize as informações abaixo sobre a 
configuração das interfaces do roteador. 


Configurações da interface WAN 


o Automatic Configuration (DHCP) - significa que o roteador receberá o endereço IP do 


provedor de internet de forma automática; 
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IP Estático na internet - endereço IP será informado pelo provedor e deverá ser confi- 
gurado manualmente; 


PPOE - utilizado para configurar o AP para se conectar a uma rede que utiliza o padrão 
(PPP over Ethernet); 


PPTP - 0 protocolo PPTP é um modelo “voluntário” de tunelamento, ou seja, permite que 
o próprio sistema do usuário final, por exemplo, um computador, configure e estabeleça 
conexões discretas ponto-a-ponto para um servidor PPTP, localizado arbitrariamente, 
sem a intermediação do provedor de acesso. Este protocolo constrói as funcionalidades 
do protocolo PPP (Point to Point Protocol). É um protocolo proprietário desenvolvido por 


um grupo liderado pela Microsoft. 


Configurações das interfaces LAN 


1. 


Local IP Address: endereço IP padrão de administração do roteador para acesso via 
navegador web; esse endereço pode ser configurável nesta mesma tela e o padrão varia 


dependendo do fabricante do ponto de acesso. 


DHCP Server (Habilitado/Desabilitado) - significa que o AP possui um servidor DHCP 
interno que pode ser habilitado ou desabilitado; opção importante, uma vez que as 
estações estão configuradas para obter endereço IP automaticamente via DHCP; se o 
servidor DHCP não estiver habilitado, as estações não obterão endereço IP e deverão ser 


configuradas manualmente, o que não é necessário em ambiente pequeno; 


Starting IP Address - endereço IP a partir do qual serão atribuídos os endereços IP para 
as estações conectadas ao roteador (via cabo ou wireless); 


No menu de configuração, a opção Status exibe informações da conexão do equipamento. 


2.1. O que pode ser observado no menu status do equipamento do laboratório? Quais as 


informações atribuídas para conexão do AP com a internet? 











2.2. Além da função de Access Point e gateway, o equipamento está exercendo uma 


função importante na interface das redes LAN e WAN. Qual é essa função? 











3. Localize a opção Wireless no equipamento do laboratório. Observe as opções de configu- 


rações (Settings) e segurança do dispositivo. 


Em Settings pode-se configurar: 


Modo de operação da interface Wireless do AP; 
Definir o SSID da interface Wireless; 
Definir o canal que a interface Wireless irá operar; 


Broadcast do SSID: alguns equipamentos permitem desabilitar a propagação do SSID 
pela interface wireless. 


4. Escolha um dos seguintes SSID e um canal de operação (um para cada grupo): 


SSID Canal 

Grupot 1 - 2.412 GHz 
Grupo2 6 - 2.437 GHz 
Grupo3 2 11 - 2.462 GHz 


Clique em Save Settings e em Continue na tela seguinte. Exemplo na figura a seguir: 


LINKSYS’ 


A Division af Cisco Systems, Inc. Firmware Version: v 1.02.2 


Wireless-G Broadband Router WRTS4G 


Wireless Access Applications Administration Status 
Setup Wireless Security Restrictions & Gaming 


Basic Wireless Setlings | 1 t Fite 1 








Wireless Network Mode: If 


h Network 


Wireless Network Mode: Mixed v you wish to exclude Wireless-G 
cients, choose B-Only Mode. If 

Wireless Network Name (SSD) grupo you would ike to disable 
witless access, chouse 


Wireless Channet |-2412GHz ¥ Disable 


Wireless SSD Broadcast © Enable © Disable More... 


Status : SES inactive 








Reset Security 
Figura 1.42 Cisco Svsrems 
Modo de rede 
wireless. Cancel Changes 


5. Feche o navegador. Desligue o cabo par trançado da porta LAN. Esse procedimento foi 


necessário apenas para configurar a rede sem fio no AP. 


® Nenhuma chave de segurança foi configurada no AP. A opção “Wireless Security 
Mode” deve ser marcada como “disabled”. 


6. Inserir o adaptador sem fio USB no computador. Deverá ser reconhecido automatica- 


mente, pois o driver de software já deverá estar previamente instalado. 
7. Localize as redes sem fio disponíveis. 


Os SSIDs deverão ser exibidos como disponíveis, escolha a rede com o SSID do seu grupo 
(grupo1, grupo2 ou grupo3). Note que poderá ser exibida uma advertência do tipo: “Rede sem 


fio não segura”, clique em Conectar. 


8. Abra uma janela DOS (Iniciar/prompt de comando ou Iniciar/Executar - digitar cmd) e 


digite o comando: ipconfig 


O resultado deverá ser semelhante ao mostrado a seguir. 
C:\>ipconfig 
(linhas removidas) 


Adaptador Ethernet Conexão de rede sem fio: 
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Sufixo DNS específico de conexão . : esr.rnp.br 


EMOer@c@ UP . o 6 ¢ so RO SINO 
Mascara Ge sub-rede s sc vs o q + 8 C55. 25/5.255,0 
Gateway pala los 


Observe que o endereço IP obtido foi (neste exemplo) 192.168.1.102, que é um endereço IP 
privado. Para ser possível a navegação na internet, o AP tem ativada a função NAT Overload, 
através da qual ele traduzirá os endereços IP privados para o endereço público da porta 
WAN (neste exemplo é o endereço IP: 200.130.26.30). 


9. Teste a navegação na internet. Qual será o seu endereço IP reconhecido na internet? 











objetivos 


Arquitetura de protocolos 


Introduzir os conceitos mais avançados de redes e descrever as funções e 


características das camadas de protocolos. 


Protocolos, interfaces, modelo OSI, arquitetura TCP/IP e camadas de protocolos. 





Conceito de protocolo 


Protocolo é um conjunto de regras que controla a interação de duas máquinas ou dois pro- a 
cessos semelhantes ou com funções semelhantes. Para que dois computadores se comu- 
niquem, é necessário que usem o mesmo protocolo. Sem protocolos, o computador não 


pode reconstruir, no formato original, a sequência de bits recebida de outro computador. 


Um protocolo é um conjunto de regras que controla a interação de duas máquinas ou dois 
processos semelhantes ou com funções semelhantes. Sem protocolos, o computador não 
pode reconstruir no formato original a sequência de bits recebida de outro computador. 

Para que dois computadores se comuniquem, é necessário que usem o mesmo protocolo 


(“que falem a mesma língua”). 


Fazendo uma analogia, pode-se dizer que sem um conjunto de regras de conduta e compor- 
tamento, várias pessoas falando ao mesmo tempo e em línguas diferentes não conseguem 


se entender em uma reunião de trabalho. 


Uma suíte de protocolos (família de protocolos) é uma coleção de protocolos que habi- 
litam comunicação em rede de uma máquina a outra. Uma suíte de protocolos é estrutu- 
rada em camadas, de forma a dividir e organizar melhor as funções. De maneira geral, as 
camadas superiores obtêm serviços das camadas inferiores, transferindo informações 


entre si através das interfaces entre camadas adjacentes. 


Arquitetura em camadas 


Objetivos da arquitetura em camadas: E 


a Estruturar o hardware e o software de um projeto de rede. 
a Dividir e organizar os problemas de comunicação em camadas hierárquicas. 


no Cada camada é responsável por uma função específica e usa as funções oferecidas 


pelas camadas inferiores. 
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oa Uma arquitetura de rede é definida pela combinação dos diversos protocolos nas 
várias camadas. J 


Para melhor estruturação do hardware e do software de um determinado projeto de rede, 
os problemas de comunicação são divididos e organizados em camadas hierárquicas. Cada 
camada é responsável por uma função específica e construída utilizando as funções e ser- 


viços oferecidos pelas camadas inferiores. 


Conceito de camada 


a 
O que faz uma camada? 


a Comunica-se somente com as camadas adjacentes. 
a Usa serviços da camada inferior. 
a Provê serviços à camada superior. 


As camadas de protocolos formam a base de uma arquitetura de rede. Elas permitem a 
decomposição de um único e complexo problema de comunicação em protocolos coopera- 
tivos mais simples, mas esta decomposição é também uma decomposição funcional. 


As camadas de protocolos resolvem classes distintas de problemas de comunicação. 
A interação entre as camadas é baseada em duas premissas básicas: 


a Cada camada se comunica somente com as camadas adjacentes (superior e inferior). 
a Cada camada usa serviços da camada inferior e provê serviços à camada superior. 


As funções e os protocolos das camadas são definidos tendo em vista essas premissas. 
Passaremos agora a descrever, de forma resumida, as funções de cada camada. 


Conceito de interface 


aa 
Conjunto de regras que controla a interação de duas máquinas ou dois processos dife- 

rentes ou com funções diferentes. As camadas de protocolos transferem informações 

entre si através das interfaces. 


Uma interface é um conjunto de regras que controla a interação de duas máquinas ou dois 
processos diferentes ou com funções diferentes. As camadas inferiores prestam serviços para 
as camadas superiores, que recebem os dados através das interfaces entre elas. Esses dados 


das camadas superiores são inseridos nas estruturas de dados das camadas inferiores. 


Modelo de Referência OSI 


a 
O modelo Open Systems Interconnection (OSI) foi lançado pela International Organization 
for Standardization (ISO) em 1984. A ISO é uma entidade que congrega institutos nacionais 
de padronização de 140 países, trabalhando em parceria com organizações internacionais, 


governos, fabricantes e consumidores: um elo entre setores públicos e privados. 


Na década de 1980, a ISO formou um grupo de trabalho para estudar o problema da incompatibili- 
dade entre as arquiteturas de comunicação de dados dos diversos fabricantes de computadores. 


Cada fabricante tinha uma arquitetura de hardware e software proprietária e, consequen- 
temente, arquiteturas de comunicação de dados incompatíveis entre si. A ideia principal era 
compatibilizar, através de camadas de protocolos, as estruturas de dados das arquiteturas 
de comunicação, de forma a permitir que as aplicações trocassem dados entre si, ainda que 


funcionando em plataformas de hardware e software de diferentes fabricantes. 


Histórico do modelo OSI 


A motivação para a criação do modelo OSI foi a ausência de compatibilidade entre as A 


arquiteturas de redes de fabricantes diferentes. | 


Em um contexto em que cada fabricante construía sua arquitetura de redes, e na ausência 
de compatibilidade entre elas, o Modelo de Referência OSI (Open Systems Interconnection) 
foi concebido para permitir a interoperabilidade das arquiteturas proprietárias de redes de 


computadores que existiam na década de 1970. 


Os primeiros trabalhos nesse sentido foram feitos por um grupo da Honeywell, em meados 
dos anos 70. Esse grupo estudou algumas das soluções existentes, incluindo o sistema da 
IBM de arquitetura de rede (SNA) e o trabalho em protocolos que estava sendo feito para a 
Arpanet (TCP/IP). O resultado desse esforço foi o desenvolvimento de uma arquitetura de 


sete camadas, conhecida internamente como a arquitetura de sistemas distribuídos (DSA). 


Enquanto isso, em 1977, o British Standards Institute propôs à ISO que criasse uma arqui- 
tetura padrão para definir a infraestrutura de comunicações para processamento distri- 
buído. Como resultado desta proposta, a ISO formou uma subcomissão de Interconexão 

de Sistemas Abertos (Comitê Técnico 97, Subcomitê 16). Quando o grupo ISO se reuniu em 
Washington, a equipe Honeywell apresentou a sua solução. Um consenso foi alcançado na 
reunião: a arquitetura em camadas satisfaria a maioria dos requisitos de Interconexão de 
Sistemas Abertos, com a capacidade de ser ampliada mais tarde para atender a novos requi- 
sitos. A versão provisória do modelo foi publicada em março de 1978. A próxima versão, com 
alguns pequenos acertos, foi publicada em junho de 1979 e, posteriormente, padronizada. 


O modelo OSI resultante é essencialmente o mesmo que o modelo DSA desenvolvido em 1977. 


Objetivos de um sistema aberto 


A norma ISO foi publicada internacionalmente pela primeira vez em 1984, sob o número 
ISO 7498, e pode ser obtida gratuitamente na internet. Os objetivos de um sistema aberto 


podem ser resumidos em: 


o Interoperabilidade - capacidade que sistemas abertos possuem de troca de infor- 


mações entre eles, mesmo que sejam fornecidos por fabricantes distintos. 


o Interconectividade - maneira pela qual os computadores de fabricantes distintos 


podem ser conectados. 


ao Portabilidade da aplicação - capacidade de um software ser executado em várias 
plataformas diferentes. 


o Escalabilidade - capacidade de um software ser executado com desempenho 
aceitável em máquinas de capacidades diversas, desde computadores pessoais até 


supercomputadores. 





Estrutura em camadas 


5 


X Capítulo 2 - Arquitetura de protocolos 


Objetivos da estrutura em camadas: 
a Reduzir complexidade. 

a Padronizar interfaces. 

ao Facilitar engenharia modular. 


a Assegurar interoperabilidade de tecnologias. 
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a Acelerar evolução. 


a Simplificar o ensino e o aprendizado. 


Aplicação 





Figura 2.1 
Modelo de 
Referência OSI. 





O modelo de referência OSI permite: 


a Avisualização das funções de comunicação de dados que ocorrem em cada camada; 
o Uma estrutura que pode ser usada para entender como a informação viaja pela rede; 
a Acompreensao, visualização e resolução de problemas ao enviar e receber dados numa rede; 


a O entendimento de como a informação ou pacote de dados trafega, com origem nos 
programas aplicativos, e através do meio físico da rede (por exemplo, fios) chega até 
outro programa aplicativo localizado em outro computador da rede, mesmo que origem 


e destino tenham diferentes tipos físicos de rede. 


O modelo estruturado em camadas reduz a complexidade dos protocolos de cada camada, 
uma vez que a modularidade de funções das camadas permite a simplificação do projeto de 


cada camada e, consequentemente, simplificam o ensino e aprendizado dos usuários da rede. 


A estrutura de camadas permite também a padronização de interfaces, assegura a intero- 
perabilidade de tecnologias utilizadas nas diversas camadas e acelera a evolução do modelo 
como um todo. 


Camadas do modelo OSI 


Modelo de 7 camadas: 
o Data Flow Layers - 4 camadas inferiores. 


a Application Layers - 3 camadas superiores. 


O modelo de 7 camadas pode ser visto como dois subconjuntos de 4 e 3 camadas, conforme 
mostra a figura seguinte. As 4 primeiras camadas (de baixo para cima) são denominadas 
Camadas Inferiores (Data Flow Layers). Elas controlam basicamente as funções de rede 

e procuram oferecer serviços de transferência de dados com qualidade aceitável para as 
aplicações que utilizam a rede. 


As 3 camadas seguintes, denominadas Camadas Superiores (Application Layers) tratam 
somente das funções específicas das aplicações, sem preocupação com os detalhes de 
redes. Assim, as aplicações podem se concentrar nas funções dos sistemas que os usuá- 
rios estão utilizando. 


Figura 2.2 
Visdo geral do 
modelo OSI. 


Camadas superiores (host layers ou application layers) 


Camadas inferiores (data flow layers) 





Camada física 


A função geral da camada física é ser responsável pela transmissão dos bits através de 


um canal de comunicação. Entre suas funções específicas podemos listar: 
ao Representação dos bits (nível elétrico, duração do sinal, codificação). 
a Forma e nível dos pulsos ópticos. 


o Mecânica dos conectores. 





a Função de cada circuito do conector. 


Na camada física, ocorre a especificação das interfaces para o meio físico, no qual o sinal 
será transmitido: 


a Partrançado - Unshielded Twisted Pair (UTP) Cat5, Cat5e, Cat6; 
o Fibra óptica monomodo ou multimodo; 

a Cabo coaxial 10Base2 e 10Base5; 

a Wireless (micro-ondas). 


O tipo de sinalização inclui a definição do nivel de sinal (voltagem) e a duração de cada bit, 
bem como as transições entre zeros e uns. A codificação dos bits provê mecanismos para 
garantir uma melhor confiabilidade na comunicação (maior detecção e correção de erros 
de interpretação dos bits). Envolve o controle da frequência de envio de zeros e uns em 
sequência, a quantidade de transições entre zeros e uns para permitir a recuperação de 
sinal de relógio etc. O tipo de codificação está altamente relacionado com a velocidade de 
transmissão dos bits no canal (meio físico). 


Tipos mais comuns de codificação: 
a NRZ- Non Return to Zero é um tipo de código de linha no qual só há tensão elétrica 


quando se transmite o símbolo 1; o símbolo O é a ausência de tensão; 


a AMI-Alternated Mark Inversion é um método de codificação nas transmissões E1 e T1, 


no qual “1s” consecutivos têm a polaridade oposta; 


o HDB3 -técnica de sinalização bipolar, ou seja, depende tanto dos pulsos positivos quanto 
dos negativos. As regras de codificação seguem as da AMI, com exceção de quando surge 
uma sequência de quatro zeros consecutivos, em que é utilizado um bit especial de violação; 
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o Manchester - tipo de código de linha usado em redes Ethernet, no qual o bit O é repre- 
sentado como uma transição positiva (subida) no meio do intervalo de sinalização do bit. 


Como bit 1 ocorre o contrário, transição negativa (descida). 


Modem 
+ CSU/DSU 
EIA/TIA-232 
DCE 
DTE V.35 Figura 2.3 
X.21 Camada fisica: 
HSSI interfaces DTE/DCE. 


Na camada física ocorre a definição dos padrões de interface: 
Data Terminal Equipment (DTE) 


Terminologia tradicional em comunicação de dados para um dispositivo que recebe ou 
origina dados sobre uma rede. Tipicamente um computador ou um terminal não progra- 


mável. Marca a terminação do dispositivo do usuário no link WAN. 
Data Communication Equipment (DCE) 


Terminologia tradicional em comunicação de dados para equipamentos que habilitam 
que um DTE comunique-se com uma linha telefônica ou circuito de dados. O DCE esta- 
belece, mantém e termina a conexão, bem como realiza as conversões necessárias para 
a comunicação. Marca a terminação do dispositivo do provedor de serviços no link WAN. 
Geralmente, este dispositivo cuida do sinal de clock (relógio de sincronismo). Também 


chamado de equipamento terminador de circuito. 


A Figura 2.3 mostra alguns dos padrões de interface mais comuns para o ambiente WAN. 
Outros padrões também dignos de nota são: V.24 (usado para comunicação entre compu- 
tador e modem telefônico), G.703 (usado para conexões E1/T1) e EIA/TIA-449, entre outros. 
Muitas vezes, o tipo de DCE usado pelo Service Provider (SP) determina o tipo de interface a 
ser utilizada no equipamento DTE (roteador, geralmente). Alternativamente, o proprietário 
do DTE, de acordo com o equipamento DTE que possui, pode solicitar ao provedor de ser- 
viços a interface física a ser usada. 


O DCE pode ser analógico (modem) ou digital (CSU/DSU - Channel Service Unit/Data Service 
Unit - Unidade de Serviço de Canal/Unidade de Serviço de Dados), dependendo do circuito da 
operadora ser analógico ou digital. A interface DTE/DCE é digital e foi muito bem padronizada, 
porque interliga equipamentos de indústrias diferentes (telecomunicações e informática). 


A camada física do modelo OSI trata das interfaces com o meio físico, e não do meio 


físico propriamente dito. 


Camada de enlace de dados 

A camada de enlace de dados tem a função geral de ser responsável pela detecção de a 
erros - Frame Check Sequence (FCS). Entre suas funções específicas podemos listar: 

o Endereços físicos de origem e destino. 

a Define protocolo da camada superior. 

a Topologia de rede. 

a Sequência de quadros. 


o Controle de fluxo. 


Figura 2.4 
Frame Check 
Sequence. 


Controle de fluxo 


Processo de início-fim 
de handshaking que 
impede que seu modem 
receba quantidade 
excessiva de dados do 
seu computador ou 

de outro modem. O 
controle de fluxo de 
software é chamado de 
XON/XOFF (transmissor 
ativado e desativado). 
O controle de fluxo de 
hardware é chamado de 
RTS/CTS (Request/Clear 
to Send). 





a Connection-oriented ou connectionless. 
Em caso de erro, pode ocorrer descarte de quadros ou correção de erros (feita por 


camada superior). 


Essa camada trata os endereços físicos das interfaces de rede (endereços MAC). No quadro 
consta a informação do protocolo de camada de rede que foi encapsulado ou, dito de outra 


forma, a quem pertencem os dados que estão sendo transportados no quadro. 


101101101 FCS 


O protocolo dessa camada é dependente da topologia do meio físico. Em enlaces WAN, essa 


camada normalmente executa procedimentos de controle de fluxo e de sequência, além da 


verificação de erros, através de um cálculo polinomial padrão executado sobre todos os bits 


do quadro, exceto o próprio FCS. 


Em enlaces LAN, normalmente apenas são executados procedimentos de verificação de erros. 
O protocolo de enlace de dados também pode ser orientado à conexão (estabelece uma 
conexão ponto-a-ponto antes de enviar os quadros) ou sem conexão (não estabelece conexão). 


Funções: 

o Transformar o meio físico de comunicação numa linha livre de erros de transmissão; 
a Estruturação dos dados em quadros (frames); 

a Acamada de enlace provê transporte dos quadros ao longo do meio físico. 

A camada de enlace também é responsável pelo controle do acesso ao meio (Media Access 


Control). Quando o meio é compartilhado, é necessária a definição de algoritmos que garantam 


que os dispositivos sejam organizados para acessar o meio de forma não conflitante. 


Analogia de acesso ao meio: todos falando ao mesmo tempo numa mesa e ninguém 
se entendendo. 


Camada de rede 
A camada de rede tem a função geral de endereçamento e roteamento. Entre suas 
funções específicas podemos listar: 

o Tratamento dos problemas de tráfego na rede: congestionamento. 

o Escolha das melhores rotas através da rede. 


o Define endereços lógicos de origem e destino associados ao protocolo da camada 3. 


o Interconecta diferentes camadas de enlace de dados. 





Principais funções da camada de rede: 
o Endereçamento - método de atribuição de endereço e de localização de um host em 
uma rede, utilizando o endereço como identificador lógico do host. 


a Roteamento - identifica o processamento e direcionamento de pacotes de dados, por 
meio de seus endereços, de uma rede para outra. 


a Tratamento dos problemas de tráfego na rede como congestionamento; 


o Escolha das melhores rotas através da rede. 
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A camada de rede também oferece os seguintes serviços: 


o Datagrama - os pacotes são enviados sem que uma conexão entre origem e destino 
seja previamente estabelecida (sem conexão). 


a Circuito virtual - antes do envio dos pacotes é estabelecida uma conexão entre 
origem e destino, que permanece enquanto durar a transferência de pacotes 


(orientado à conexão). 


Dispositivos da camada de redes (camada 3) cuidam do endereçamento lógico (ex.: ende- 
reços IP, endereços IPX, endereços Apple Talk). Exemplo: roteadores. 


Note que a camada 2 cuidava do endereçamento físico (ex.: endereços MAC). 


Trata do roteamento dos pacotes da origem até o destino 
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Figura 2.5 
Camada de rede. 





Camada de transporte 


A camada de transporte tem a função geral de conectividade fim-a-fim. Entre suas 
funções específicas podemos listar: 


a Recebe os dados da camada de sessão, os divide se necessário, e passa-os para a 
camada de rede. 


a Garante que todas as partes cheguem corretamente ao destino. 

a Implementa uma conversação fim-a-fim. 

a Responsável pelo término e pela criação de conexões, quando necessário. 

a Controle de fluxo fim-a-fim. 

a Identifica as aplicações de camadas superiores. 

ao Estabelece conectividade fim-a-fim entre aplicações. 

a Oferece serviços confiáveis, ou não, para a transferência dos dados. 

Conforme a camada de transporte envia seus segmentos de dados, ela também deve 


assegurar a integridade dos dados. Para garantir a integridade dos dados, a camada de 
transporte é orientada à conexão (connection-oriented). 


Algumas razões para a realização de transporte confiável: 


a Assegurar que o dispositivo de origem da informação receba reconhecimento 


(acknowledgement) dos segmentos entregues; 


ao Permitir a retransmissão de quaisquer segmentos sobre os quais não forem fornecidos 
reconhecimentos; 


a Reorganizar segmentos na ordem correta no dispositivo de destino, já que os pacotes de 
origem podem seguir diferentes caminhos, com diferentes tempos de entrega ao destino 
e, portanto, chegando fora da ordem original; 


ao Permite controlar e compatibilizar a taxa de envio e recepção de dados através do 
controle de fluxo. 


Exemplos de protocolos da camada de transporte: TCP e UDP (da pilha de protocolos IP) 
e SPX (da pilha de protocolos IPX Novell): 


a TCP é orientado à conexão (connection-oriented) e, portanto, oferece serviço confiável, 
isto é, garantia de entrega ao destinatário; 


ao UDP é dito não orientado à conexão (connectionless). Oferece velocidade e simplicidade, 
mas não oferece confiabilidade. 


A funcionalidade de transporte é realizada segmento a segmento. Isto significa que dife- 
rentes segmentos de dados provenientes de diferentes aplicações (enviados para o mesmo 
ou para muitos destinos) são enviados na base “first come, first served” (primeiro a chegar, 
primeiro a ser processado). 


Camada de sessão 


pm 
A camada de sessão tem a função geral de permitir que aplicações em diferentes máquinas 


estabeleçam uma sessão entre si. Entre suas funções específicas podemos listar: 


a Gerencia o controle de diálogos, permitindo a conversação em ambos os sentidos, 
ou em apenas um. 


a Sincronização do diálogo (transferência de arquivos, programas). 


A camada de sessão permite que duas aplicações em computadores diferentes estabeleçam 
uma sessão de comunicação. Nesta sessão, essas aplicações definem a forma como será 
feita a transmissão de dados, e coloca marcações nos dados que estão sendo transmitidos. 
Se porventura a rede falhar, os computadores reiniciam a transmissão dos dados a partir da 
última marcação recebida pelo computador receptor. 


A camada de sessão disponibiliza serviços como pontos de controle periódicos, a partir dos 


quais a comunicação pode ser restabelecida em caso de pane na rede. 


A camada de sessão (camada 5) estabelece, gerencia e termina sessões entre aplicações. 
Ela coordena as solicitações e respostas de serviços que ocorrem quando aplicações de 
diferentes hosts estabelecem comunicação. 


Camada de apresentação 
A camada de apresentação tem a função geral de representação da informação: sintaxe A 
e semântica. Entre suas funções específicas podemos listar: 


o Realiza certas funções de forma padrão, como por exemplo, conversão de códigos de 
caracteres (EBCDIC, ASCII etc). 


a Compressão, criptografia, codificação de inteiro, ponto flutuante etc. 
A camada de apresentação, também chamada de camada de tradução, converte o formato 


do dado recebido pela camada de aplicação em um formato comum a ser usado na trans- 


missão desse dado, ou seja, um formato entendido pelo protocolo usado. 
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Um exemplo comum é a conversão do padrão de caracteres (código de pagina) quando o 


dispositivo transmissor usa um padrão diferente do padrão ASCII, padrão muito usado em. ASCII. 

todo o mundo. Podem existir outros usos, como compressão de dados e criptografia. Americam Standard 
Code for Information 

A compressão de dados processa os dados recebidos da camada 7 e os comprime como se Interchange, padrão 


no qual números, 


letras maiúsculas e 
camada de apresentação do dispositivo receptor fica responsável por descompactar esses minúsculas, sinais de 


fosse um compactador comumente encontrado em computadores (como Zip ou Rar), e a 


dados. A transmissão dos dados torna-se mais rápida, já que haverá menos dados a trans- pontuação, símbolos e 
códigos de controle cor- 
respondem a números 
de sessão. binários de 0 a 127. 


mitir: os dados recebidos da camada de aplicação foram “encolhidos” e enviados à camada 


Para aumentar a segurança, pode-se usar algum esquema de criptografia neste nível, sendo 
que os dados só serão decodificados na camada de apresentação do dispositivo receptor. 


Funções da camada de apresentação (camada 6) do modelo OSI: 


a Responsável pela apresentação de dados numa forma que o dispositivo de destino 


possa compreender; 


a Serve como tradutor, às vezes entre formatos diferentes, para dispositivos que 
necessitam se comunicar pela rede; 


ao Outra função é a cifração/decifração de dados. 


Camada de aplicação 


A camada de aplicação define uma variedade de protocolos necessários à comunicação. d 
Exemplos: terminais virtuais, transferência de arquivos, correio eletrônico, áudio e video- 
conferência, acesso remoto, gerência de redes. 


A camada de aplicação faz a interface entre o protocolo de comunicação e o aplicativo que 
pediu ou receberá a informação através da rede. Por exemplo, ao solicitar a recepção de 
e-mails através do aplicativo de e-mail, este entrará em contato com a camada de aplicação 
efetuando tal solicitação. Tudo nesta camada é direcionado aos aplicativos. Terminal remoto 


e transferência de arquivos são exemplos de aplicativos de rede. 


Esta camada trata de questões relacionadas às aplicações de rede, e não às aplicações de com- 
putador não baseadas em rede. Aplicações como planilhas eletrônicas, processadores de texto 
e apresentações no PowerPoint não são aplicações de rede. Correio eletrônico, transferência de 


arquivos, acesso remoto e áudio/videoconferência, entre outras, são aplicações de rede. 


® A camada de aplicação do modelo OSI refere-se aos protocolos adotados pelas apli- 
cações de rede e não as próprias aplicações de usuário. 


Encapsulamento de dados 


Processo que assegura a correta transferência e recuperação de dados - Protocol Data a 
Unit (PDU). |] 


Após a breve descrição das camadas do Modelo de Referência OSI apresentada, vamos 
exemplificar como as camadas de protocolos transferem informações. 


Figura 2.6 
Processo de 
encapsulamento 
de dados. 
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A Figura 2.6 ilustra o processo de transferência de dados da aplicação em uma arquitetura 
de rede, que, para simplificar, adota apenas 4 camadas, onde os dados da aplicação são 
entregues à camada de transporte; esta precisa adicionar informações de controle aos 
dados, para que a camada de transporte do outro lado possa saber o que fazer com os 
dados. Essas informações são o cabeçalho de transporte. O conjunto cabeçalho/dados é 
chamado de Protocol Data Unit - PDU (Unidade de Dados do Protocolo) da camada de 


transporte. Em geral, essa PDU é chamada de Segmento. 


A PDU de transporte é entregue à camada de rede que, por sua vez, adiciona suas informa- 
ções de controle para que os dados possam trafegar pelas redes entre origem e destino. 
Essas informações são o cabeçalho de rede. O conjunto cabeçalho/dados é chamado de 
Protocol Data Unit - PDU (Unidade de Dados do Protocolo) da camada de rede. Geralmente, 
essa PDU é chamada de Datagrama ou Pacote. 


A PDU de rede é entregue à camada de enlace de dados que, por sua vez, adiciona suas 
informações de controle para que os dados possam trafegar pelo meio físico, entre origem e 
destino. Essas informações são o cabeçalho de enlace de dados. O conjunto cabeçalho/dados 
também é chamado de PDU da camada de enlace de dados. Essa PDU é chamada de Quadro. 


Finalmente, esse conjunto de informações é enviado pelo meio físico na forma de um fluxo 


de bits desestruturados. A camada física não tem ideia do que esse fluxo de bits representa. 


Comunicação par-a-par 


am 
Comunicação em que os pontos se comunicam através da PDU de suas respectivas camadas. 


Por exemplo, as camadas de rede da origem e destino são pares e usam pacotes | 


para se comunicar. 
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Dados 
Aplicação Aplicação 
Dados 2 
Apresentação Apresentação 
Sessão 
Segmentos 
Transporte Transporte 
Pacotes 
Enlace de dados Quadros Enlace de dados 
Bit Comunicação 
Física La Física par-a-par no 
modelo OSI. 


Cada camada usa seu próprio protocolo e os serviços da camada inferior para estabelecer 


Figura 2.7 





comunicação com sua camada par no outro sistema. 


Arquitetura TCP/IP 


a Modelo DoD. 

a Documentos de padronização. 

oa Conceito de inter-rede. 

a Características básicas. 

a Funções das camadas. 

o Tipos de endereços (lógico e físico). 


Essa arquitetura foi concebida para interligar os centros de computação das universidades 
americanas. Portanto, surgiu como uma rede acadêmica, não como uma rede comercial ou 


pública de qualquer natureza. 


A alternativa existente na época (década de 1960) era a interligação via linhas telefônicas 
dedicadas (LPs) utilizando equipamentos e software dos fabricantes dos grandes main- 


frames, principalmente a IBM. 


Esse projeto foi concebido no Departamento de Defesa dos EUA e é conhecido como modelo 
Department of Defense (DoD). A documentação do projeto foi elaborada pela comunidade 
acadêmica americana envolvida no desenvolvimento do projeto. A proposta da rede inovou 
em muitos aspectos os conceitos de rede existentes na época e foi tão bem aceita que 


perdura até os dias de hoje, mantendo sua concepção original nas linhas gerais. 


A seguir passamos a descrever as características desse projeto em maiores detalhes. 
Histórico 

Origem em um projeto militar, desenvolvido a partir de proposta da RAND Co. de 1964, 
como início do desenvolvimento em 1969. Comutação de pacotes: 

a Rede não confiável. 


a Mensagens divididas em pedaços (pacotes). 


o Roteamento independente por pacote. 


Para obter estes 

padrões, pesquise por 
“rfcindex”. Se souber o 
número do RFC, faça a 


pesquisa em: http:// 


RFC desejado. 





Comutação de pacotes 


Técnica de comutação 
em que a comunicação 
entre as extremidades 
se processa através da 
transmissão de blocos 
(pacotes) de informação, 
havendo ocupação do 
canal apenas durante 
o envio dos pacotes, 
liberando-o para 

outra informação 

nos espaços livres. 


o Armazena e encaminha (store and forward). 


o Rede experimental ARPAnet. | 


Na década de 60, a RAND Corporation, uma das maiores empresas americanas envolvidas 

em estratégias para a Guerra Fria, se deparou com um estranho problema estratégico: como 
as autoridades governamentais americanas poderiam continuar se comunicando após uma 
guerra nuclear? Além disso, havia a questão da forma como a própria rede poderia ser coman- 
dada e controlada. Qualquer autoridade central ou quartel general central seria um alvo óbvio 


e imediato para um míssil inimigo. O centro da rede seria o primeiro lugar a ser destruído. 


A RAND se ocupou deste quebra-cabeça com segredo militar, e chegou a uma solução 
audaciosa. A proposta da RAND se tornou pública em 1964. Em primeiro lugar, a rede não 
teria “nenhuma autoridade central”. Além disso, ela seria projetada desde o princípio para 
operar mesmo destroçada. O princípio era simples: assumiu-se que a rede não era confiável 
o tempo todo. Ela seria projetada tendo em mente a ideia de “receber e passar adiante”, de 
modo a transcender sua própria falta de confiabilidade. Cada nó da rede seria igual a todos 
os outros nós da rede (em termos de status e função), cada um com sua própria autoridade 
para originar, passar e receber mensagens. 


As mensagens por sua vez seriam divididas em pacotes, com cada pacote endereçado 
separadamente. Cada pacote começaria de um nó de origem e terminaria no nó de destino 
final especificado. Cada pacote “viajaria” pela rede sendo tratado de forma individual. A rota 
seguida por cada pacote através da rede não teria importância. Apenas os resultados finais 
teriam importância. Basicamente, o pacote seria passado como uma batata quente, de nó 
para nó, mais ou menos na direção do seu destino final, até chegar ao destino correto. Se 
grande parte da rede tivesse sido explodida, isso simplesmente não importaria; os pacotes 
ainda permaneceriam na rede, percorrendo os nós que eventualmente ainda sobrevi- 
vessem. Este sistema de transmissão desorganizado pode ser ineficiente quando compa- 


rado, por exemplo, com o sistema telefônico; no entanto, ele seria extremamente robusto. 


A rede experimental formada pelas universidades americanas foi chamada de ARPAnet. 
As especificações dos protocolos foram elaboradas através de documentos chamados RFCs - 


Request for Comments (Solicitação de Comentários), que se tornaram os padrões universais. 


Década de 70 


1970-1979: 


a Agência Arpa desenvolve estudos para interconexão de redes baseada em comutação 
de pacotes. 


a Construção da rede ARPAnet. 


o Surgem as primeiras especificações da família de protocolos TCP/IP para definição 
dos detalhes de comunicação e convenções para interconectar as redes e realizar o 
roteamento de tráfego. 





Em meados da década de 70, em função da importância da tecnologia de inter-redes, uma 
agência do Departamento de Defesa (DoD) do governo americano, Advanced Research 
Projects Agency (Arpa), financiou pesquisas para desenvolvimento de uma tecnologia de 
inter-redes baseada na comutação de pacotes. Dessa iniciativa, resultou a construção da 


rede ARPAnet. 


A tecnologia Arpa inclui um conjunto de padrões de redes que especificam os detalhes da 


comunicação entre os computadores, além de um conjunto de convenções para interco- 
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nectar as redes individuais e realizar o roteamento do tráfego entre elas. Essa tecnologia, 


oficialmente denominada família de protocolos TCP/IP, é conhecida como TCP/IP. 
Década de 80 


1980-1985: 
ao Família de protocolos TCP/IP é padronizada na ARPAnet. 
a Início da emergente internet. 
ao Arpanet é dividida em duas redes: 
m Pesquisa experimental (ARPAnet). 
a Comunicação militar (Milnet). 


a Arpa disponibiliza implementação de baixo custo do TCP/IP e financia a integração em 
sistemas Unix. 


No início da década de 80, a Arpa adotou a família de protocolos TCP/IP em suas redes de 
pesquisas, demarcando o início da internet. Posteriormente, em 1983, a ARPAnet foi dividida 
em duas redes: uma para pesquisa experimental, que continuou a ser denominada ARPAnet, 
e outra para comunicação militar, que foi denominada Milnet. 


Para incentivar a adoção da família de protocolos TCP/IP em universidades e centros de 
pesquisa, a Arpa ofereceu uma implementação de baixo custo e financiou a integração dos 
protocolos TCP/IP em sistemas Unix. Como resultado, a distribuição do BSD Unix da Univer- 
sidade de Berkeley incorporou novos serviços e disponibilizou mecanismos que facilitaram a 


programação de aplicações distribuídas usando os protocolos TCP/IP. 


Década de 90 


1985-1990: 


a National Science Foundation (NSF) incentiva a expansão de redes TCP/IP para a 
comunidade científica. 


a Criação do backbone da rede NSFNET. 
m Interligação de centros de supercomputação. 
m Conexão com a ARPAnet. 
a Adoção dos protocolos TCP/IP por organizações comerciais. 


o Crescimento do tamanho e uso da internet no mundo. 


Em 1985, a National Science Foundation (NSF), agência de fomento de ciências do governo 
americano, incentivou a expansão de redes TCP/IP para a maioria dos cientistas americanos, 
por reconhecer o potencial da comunicação em rede para a comunidade científica. Como 
resultado desse esforço, surgiu um novo backbone de longa distância, denominado NSFNET, 


que interligava todos os centros de supercomputação e se conectava com a ARPAnet. 


A partir de 1986, a NSF financiou diversas redes regionais com o objetivo de interconectar 

a comunidade científica das várias regiões. Todas estas redes adotavam os protocolos TCP/ 
IP e faziam parte da assim denominada internet. Cerca de sete anos após seu surgimento, a 
internet já era composta por centenas de redes localizadas nos Estados Unidos e na Europa. 
Desde então, continuou a crescer rapidamente, em tamanho e em uso. A adoção dos proto- 
colos TCP/IP e o avanço da internet não se limitaram a projetos financiados pelas agências 
governamentais. A partir de 1990, diversas organizações comerciais adotaram os protocolos 


TCP/IP e começaram a se conectar à internet. 


Embora inicialmente tenha sido um projeto de pesquisa financiado pelo governo americano, a 
adoção dos protocolos TCP/IP excedeu as expectativas originais. A intenção inicial era desen- 
volver uma tecnologia de interconexão de redes baseada na técnica de comutação de pacotes. 
Hoje, essa família de protocolos forma a base tecnológica da internet, a maior rede de longa 
distância existente e, reconhecidamente, o exemplo mais expressivo de interconexão de redes 
de computadores, pois interconecta milhões de computadores em universidades, escolas, 
empresas e lares. 


Família de protocolos TCP/IP 


7 
Conjunto de padrões de redes que permite a interconexão de redes e sistemas hete- a 
rogêneos, como redes físicas com diferentes tecnologias de acesso, e equipamentos 
desenvolvidos por diferentes fabricantes, com arquiteturas de hardware distintas que 
executam diferentes sistemas operacionais. 


Quem pode usar? 


a Qualquer organização que queira interconectar suas diversas redes na forma de uma 
inter-rede. 





o Não requer uma conexão com a internet. 


A família de protocolos TCP/IP permite a interconexão de diferentes tipos de computadores 
de diversos fabricantes, equipados com arquiteturas distintas de hardware, executando 


múltiplos sistemas operacionais e usando diferentes tecnologias de acesso. 


A internet é apenas uma demonstração concreta da viabilidade da tecnologia TCP/IP. Essa 
família de protocolos pode ser utilizada, por qualquer organização, como tecnologia para 
conectar internamente os componentes de uma única rede ou para interconectar suas diversas 


redes na forma de uma inter-rede, independentemente de estar ou não conectada à internet. 


Para entender o funcionamento da família de protocolos TCP/IP, vamos apresentar o modelo 
de interconexão desse tipo de rede, enfatizando os mecanismos que viabilizam a interação 
dos diversos protocolos. As diversas tecnologias de redes definem como os dispositivos 
devem se conectar às respectivas redes. Já uma tecnologia de inter-rede define como as 
redes são interconectadas entre si, permitindo que cada equipamento possa se comunicar 
com os demais equipamentos das várias redes. 


Em uma inter-rede TCP/IP, duas ou mais redes físicas somente podem ser interconectadas 
por um equipamento especial, chamado roteador, cuja função é encaminhar pacotes de uma 
rede para outra. Para rotear corretamente os pacotes, os roteadores precisam conhecer 

a topologia da inter-rede, e não apenas as redes físicas às quais estão diretamente conec- 
tados. Assim, eles precisam manter informações de roteamento de todas as redes que 
fazem parte da inter-rede. 


Os usuários enxergam a inter-rede como uma rede virtual única à qual todos os disposi- 
tivos estão conectados, independentemente da forma das conexões físicas. Para isso, uma 
inter-rede TCP/IP adota um mecanismo de endereçamento universal, baseado em ende- 


reços IP, que permite a identificação única de cada dispositivo. 
Motivação para nova família de protocolos 


A evolução das tecnologias de comunicação e a redução dos custos dos computadores 
constituem os principais fatores para a ampla adoção das redes de computadores nas orga- 
nizações. As redes são projetadas, essencialmente, para compartilhar recursos de hardware 


e software e viabilizar a troca de informações entre usuários. No entanto, as atuais tecnolo- 
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gias de redes restringem o número de dispositivos conectados e são, geralmente, incom- 
patíveis entre si. Por exemplo, dispositivos conectados a uma rede que adota a tecnologia 
Ethernet não interagem diretamente com outros que utilizam a tecnologia Token Ring. Isso 
dificulta a comunicação entre grandes grupos de usuários, e impede que usuários de redes 
distintas se comuniquem entre si. 


Solução para nova família de protocolos 


Alternativas: 

a Adotar mecanismos que permitam a interoperabilidade. 

o Interconectar as diferentes redes. 

a Compatibilizar a heterogeneidade das múltiplas tecnologias de redes. 

A solução para isso é a tecnologia de inter-redes. 

Para viabilizar essa comunicação, a única alternativa é adotar mecanismos que permitam a 


interoperabilidade, interconectando e compatibilizando as múltiplas redes heterogêneas. 
A interconexão dessas várias redes é denominada inter-rede. 


Tecnologia de inter-redes 


am 
Conjunto de protocolos que permitem a interconexão de redes heterogêneas. Benefícios: 

a Acomoda múltiplas plataformas de hardware e software. 

a Esconde detalhes do hardware de rede. 


a Permite a comunicação dos dispositivos de forma independente do tipo de rede 
física adotada. 


Nas últimas décadas, a tecnologia de inter-redes foi desenvolvida para possibilitar a 
interconexão de diferentes tipos de tecnologias de redes, acomodando múltiplas plata- 
formas de hardware e software, com base em um conjunto de protocolos que definem as 
regras de comunicação. Essa tecnologia esconde detalhes do hardware de rede e permite 


que os dispositivos se comuniquem, independentemente do tipo de rede física adotada. 





Figura 2.8 
Modelo inter-rede. 


Modelo de interconexão 


Roteador: 

a Possui conexões com duas ou mais redes. 

a Não provê conexão direta com todas as redes físicas. 

a Roteia pacotes de uma rede para outra. 

a Mantém informações de roteamento para todas as redes. 

o Também denominado gateway ou sistema intermediário. 

Estação: 

a Dispositivo do usuário conectado a alguma rede física da inter-rede. 


o Estação multihomed pode atuar como um roteador; requer ativação da função de 
roteamento de pacotes entre redes. 


o Também denominada host ou sistema final. 
Visão do usuário: 


a Usuários veem a inter-rede como uma rede virtual única à qual todos os dispositivos 
estão conectados. 


o Usuários não conhecem as diversas redes físicas individuais. 


a Adota um mecanismo de endereçamento universal, baseado em endereços IP, que 


permite a identificação única de cada dispositivo da inter-rede. 


A Figura 2.8 ilustra o modelo de interconexão de uma inter-rede TCP/IP. Neste exemplo, 
quando a estação E1 deseja enviar pacotes para a estação E3, encaminha os pacotes através 
da rede N1 para o roteador R1, que, por sua vez, entrega-os diretamente para a estação E3, 
através da rede N2. 


É importante notar que os roteadores não estabelecem conexão direta entre todas as redes 
físicas. Para alcançar um determinado destino, pode ser necessário encaminhar os pacotes 
através de diversos roteadores e redes intermediárias. Observe que podem existir dife- 
rentes alternativas de encaminhamento dos pacotes entre alguns pares de estações. 


No exemplo da figura, quando a estação E1 deseja transmitir pacotes para a estação E5, 
pode encaminha-los, através da rede N1, para os roteadores R1 ou R3, que se apresentam 
como possíveis alternativas até o destino. Se E1 adotar o caminho via R1, este, por sua vez, 
roteia os pacotes para o roteador R2 através da rede N2. Por fim, R2 entrega os pacotes para 


a estação E5 através da rede N3. 


Por definição, um roteador possui conexões físicas com duas ou mais redes. Qualquer dis- 
positivo que possua várias conexões físicas é denominado multihomed. Uma estação pode 
também ser multihomed. Caso o roteamento de pacotes seja habilitado, uma estação 
multihomed pode operar como um roteador. Portanto, roteadores não são, necessariamente, 
equipamentos especializados na função de roteamento, mas podem ser estações convencio- 


nais com várias conexões físicas e que possuem a função de roteamento configurada. 


No TCP/IP, estações são também conhecidas como hosts ou sistemas finais. Por ser a 
internet um exemplo concreto de inter-rede TCP/IP, pode-se concluir que ela é composta 
por uma coleção de diferentes redes físicas independentes, interconectadas por meio de 
diversos roteadores. Entretanto, essa estrutura de interconexão de redes não é percebida 
pelos usuários da internet, que a veem apenas como uma rede global única que permite a 


comunicação das estações a ela conectadas. 








Capítulo 2 - Arquitetura de protocolos 


X 


o>) 
a 


Ñ Arquitetura e Protocolos de Rede TCP-IP 


[en] 
N 


A inter-rede adota um mecanismo de endereçamento universal baseado em endereços IP, que 
permite a identificação única de cada dispositivo na inter-rede, não importando em qual rede 
física ele está conectado. É baseado nesse mecanismo de endereçamento universal que os 


roteadores encaminham os pacotes entre as diversas redes físicas que compõem a inter-rede. 
Arquitetura em camadas 


Uma arquitetura de rede, tal como a definida pela família de protocolos TCP/IP, é uma combi- 
nação de diferentes protocolos nas várias camadas. 


Host Unix Host Unix 
Host Unix 
TCP 





Gateway Gateway 


S Figura 2.9 
o TCP - Transmission Control Protocol Concepção da 


o IP - Internet Protocol arquitetura TCP/IP. 


A Figura 2.9 resume a concepção da arquitetura TCP/IP. Os dois principais protocolos são o TCP 
e o IP, que fazem as funções das camadas de Transporte e Rede, respectivamente. Abaixo do 
IP está a rede física e acima do TCP a aplicação. O TCP, padronizado pelo RFC 793, é um proto- 


colo fim-a-fim, denominado pelos projetistas da internet como “Host to Host Protocol”. 


O IP, encarregado do roteamento de pacotes e padronizado pelo RFC 791, é o protocolo 
inter-redes ou Internet Protocol. O gateway que conecta o host à internet, é o que hoje cha- 
mamos de roteador. Ainda é usada a denominação “gateway padrão” para indicar o ende- 
reço do roteador que faz a conexão de um host com as demais redes. 


Camadas da arquitetura TCP/IP 


A arquitetura de rede definida pela família de protocolos TCP IP é denominada arquitetura 
internet TCP/IP, ou simplesmente arquitetura TCP/IP. Conforme ilustra a Figura 2.10, a arqui- 


tetura TCP/IP é organizada em quatro camadas: Aplicação, Transporte, Rede e Interface de 


Rede (Rede Física). 
Mensagem Aplicação FTP, SMTP, HTTP 
Segmento TCP / Datagrama UDP TCP / UDP 


Datagrama IP IP / ICMP 


Figura 2.10 
Quadro Interface de rede Ethernet, Token Ring Camadas da 
arquitetura TCP/IP. 





Protocolo orientado 
a conexão 


Adota o conceito de 
conexão para gerenciar 
a comunicação 

entre as entidades 
comunicantes. 







Trata cada unidade 

de dados como uma 
entidade individual, que 
é enviada da origem ao 
destino sem a neces- 
sidade de estabelecer 
uma conexão entre as 
entidades comunicantes. 


Camada de aplicação 


gJ 
A camada de aplicação define a sintaxe e a semântica das mensagens trocadas entre 
aplicações. É a única camada cuja implementação é realizada através de processos do 

sistema operacional. 


A camada de aplicação trata os detalhes específicos da cada tipo de aplicação. Na família de 
protocolos TCP/IP, existem diversos protocolos de aplicação que são suportados por quase 
todos os sistemas. Por exemplo: 

o Telnet -terminal virtual; 

o FTP (File Transfer Protocol) - transferência de arquivos; 

a SMTP (Simple Mail Transfer Protocol) - correio eletrônico; 

a SNMP (Simple Network Management Protocol) - gerenciamento de redes; 

o DNS (Domain Name System) - mapeamento de nomes em endereços de rede; 


o HTTP (Hypertext Transfer Protocol) - WWW (World Wide Web). 


Cada protocolo de aplicação define a sintaxe e a semântica das mensagens trocadas entre 
os programas de aplicação. Em geral, a camada de aplicação é implementada usando 
processos de usuários, que são representações do sistema operacional para programas em 
execução. Por outro lado, as demais camadas (transporte, inter-rede e interface de rede) são 


implementadas diretamente no núcleo (Kernel) do sistema operacional. 


Camada de transporte 


A camada de transporte provê comunicação fim-a-fim entre aplicações. 
TCP (Transmission Control Protocol): 

a Orientado à conexão. 

o Provê fluxo confiável de dados. 

a Divide o fluxo de dados em segmentos. 


UDP (User Datagram Protocol): 





a Provê serviço de datagrama não confiável. 


A camada de transporte provê a comunicação fim-a-fim entre aplicações. A arquitetura 
TCP/IP define dois diferentes protocolos de transporte: 


a TCP -Transmission Control Protocol é um protocolo orientado a conexão que provê 


um fluxo confiável de dados, oferecendo serviços de controle de erro, controle de fluxo 
e sequência. O TCP divide o fluxo de dados em segmentos que são enviados de uma 
estação para outra de forma confiável, garantindo que sejam entregues à aplicação 


destino na sequéncia correta e sem erros. 


er ples, não 
que oferece um serviço de datagrama não confiável. O UDP apenas envia pacotes, 
denominados datagramas UDP, de uma estação para outra, mas não garante que sejam 
entregues à aplicação destino. 
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Camada de rede 


A camada de rede realiza transferência e roteamento de pacotes entre dispositivos 
da inter-rede. 


IP (Internet Protocol): 

o Provê serviço de datagrama não confiável. 
o Envia, recebe e roteia datagramas IP. 
ICMP (Internet Control Message Protocol): 


ao Permite a troca de informações de erro e controle entre camadas de rede de 


estações distintas. 


A camada de rede, também conhecida como camada de inter-rede, é responsável pela trans- 
ferência de dados entre dispositivos da inter-rede. É nela que se realiza a função de rotea- 


mento. Os principais componentes desta camada são os seguintes protocolos: 


o IP-o Internet Protocol oferece um serviço de datagrama não confiável entre dispositivos 
da inter-rede. O protocolo IP envia, recebe e roteia pacotes, denominados datagramas IP, 
entre as várias estações da inter-rede, mas não garante que os mesmos sejam entregues 
a estação destino. Com isso, datagramas podem ser perdidos, duplicados ou chegarem 


em sequência diferente daquela em que foram enviados. 


o ICMP -o Internet Control Message Protocol auxilia o protocolo IP, pois é usado pelas 
camadas de rede de estações distintas para troca de mensagens de erro e outras infor- 


mações de controle essenciais. 


Camada de interface de rede 


a Compatibiliza a tecnologia da rede física com o protocolo IP. 

ao Aceita datagramas IP e transmite na rede física sob a forma de quadros. 
o Trata os detalhes de hardware da conexão física e transmissão de dados. 
a Geralmente inclui o driver de dispositivo e a placa de rede. 


A camada de interface de rede, também conhecida como camada de enlace de dados, é res- 
ponsável por aceitar datagramas IP da camada de rede e transmiti-los, na rede física especi- 


fica, na forma de quadros. Ela compatibiliza a tecnologia da rede física com o protocolo IP. 


Geralmente, esta camada inclui o driver de dispositivo no sistema operacional e a respectiva 
placa de rede, tratando os detalhes de hardware para conexão física com a rede e trans- 
missão de dados no meio físico. Assim, podemos dizer que a camada de interface de rede é 
basicamente suportada pela própria tecnologia da rede física. 


Encapsulamento 


Os processos de encapsulamento e desencapsulamento são essenciais para a compre- 
ensão do funcionamento da arquitetura em camadas TCP/IP. Em qualquer arquitetura em 
camadas, inclusive na arquitetura TCP/IP, os dados são gerados pelas aplicações e, em 
seguida, descem na pilha de protocolos até serem efetivamente enviados através da rede 
física. Durante a descida na pilha de protocolos, esses dados passam por um processo deno- 


minado encapsulamento. 


Figura 2.11 
Processo de encap- 
sulamento TCP/IP. 








Dados de aplicação 


Mensagem da aplicação 


Segmento TCP / Datagrama UDP 


A Figura 2.11 mostra o processo de encapsulamento que ocorre quando uma aplicação envia 
dados na arquitetura TCP/IP. Conforme se pode constatar, cada camada adiciona informa- 
ções de controle aos dados recebidos da camada imediatamente superior e, em seguida, 
entrega os dados e o controle adicionados à camada inferior. 


Os dados recebidos e as informações de controle de uma camada são conjuntamente 
denominados “unidade de dados do protocolo” da camada (Protocol Data Unit ou simples- 
mente PDU). É importante notar que a unidade de dados do protocolo de uma determinada 


camada é encapsulada diretamente no campo de dados da camada imediatamente inferior. 


Na arquitetura TCP/IP, o processo de encapsulamento começa com a entrega dos dados 

a serem transmitidos para a entidade da camada de aplicação, que, por sua vez, monta 
mensagens do protocolo específico da aplicação. Tais mensagens são entregues à camada 
de transporte. Cada aplicação decide o mecanismo de transporte que deve utilizar. Se a apli- 
cação adota o protocolo TCP, as mensagens são encapsuladas em segmentos. O protocolo 
TCP divide o fluxo de dados em segmentos que são enviados de uma estação para outra de 
forma confiável, garantindo que sejam entregues à aplicação destino na sequência correta 

e sem erros. Se a aplicação adota o protocolo UDP, as mensagens são encapsuladas em 
datagramas UDP. O protocolo UDP apenas envia pacotes, denominados datagramas UDP, de 


uma estação para outra, mas não garante que sejam entregues à aplicação destino. 


Os dois protocolos de transporte, TCP e UDP, transportam suas unidades de dados (seg- 
mentos e datagramas) usando o protocolo IP. Dessa forma, segmentos TCP e datagramas UDP 
são igualmente encapsulados no campo de dados de datagramas IP. Por fim, datagramas IP 


são encapsulados em quadros da rede física, para serem efetivamente transmitidos. 


Na prática, o protocolo IP é utilizado pelos protocolos ICMP, TCP e UDP. Assim, cada datagrama 
IP deve utilizar algum identificador no cabeçalho para indicar o protocolo que está sendo encap- 
sulado no campo de dados. Essa identificação é realizada usando um campo do cabeçalho do 
datagrama IP, denominado protocol (protocolo), que contém os valores 1, 6 e 17 para sinalizar 


que os dados transportados pertencem aos protocolos ICMP, TCP e UDP, respectivamente. 


Da mesma forma, diferentes aplicações podem utilizar os protocolos TCP e UDP como meca- 
nismos de transporte. Para isso, cada segmento TCP e cada datagrama UDP devem utilizar 


algum identificador no cabeçalho para indicar a aplicação que está sendo encapsulada no 
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campo de dados. Essa identificação é realizada usando o conceito de porta, um número 
inteiro associado a cada programa de aplicação específico. Os cabeçalhos de segmentos TCP 


e datagramas UDP possuem campos que identificam as portas das aplicações comunicantes. 


® 
Exercício de fixação iG 
Demonstração do processo de encapsulamento 


Para exemplificar as camadas de protocolos, vamos analisar um quadro capturado em uma rede 
local Ethernet durante uma sessão de um host com um servidor web, que usa o protocolo de 
aplicação HTTP, e o protocolo de transporte TCP. Mostraremos o processo de encapsulamento 


descrito na parte teórica. Recorde a Figura 2.11, que mostra o processo de encapsulamento. 


Para que possamos analisar conjuntamente o mesmo quadro, usaremos um arquivo com os 
quadros previamente capturados, nomeado “Sessao2 captura”. Para abrir este arquivo de 
captura, utilizando o Wireshark, selecionamos o ícone da barra de ferramentas que repre- 
senta uma pasta (6º da esquerda para a direita). 


Para esta análise, selecionamos o pacote nº 258, enviado do servidor web para o host do 
usuário, exatamente como mostrado na figura a seguir (tela principal do Wireshark). Neste 
caso, ambos estão na mesma rede local. 


No. Time Source Destination Protocol Length Info 
258 7.325574 192.168.0.1 192.168.0.199 HTTP 132 HTTP/1.1 200 OK 


Frame 258: 132 bytes on wire (1056 bits), 132 bytes captured (1056 bits) 


+ 


|+| 


Internet Protocol Version 4, Src: 192.168.0.1 (192.168.0.1), Dst: 192.168 
Transmission Control Protocol, src Port: http (80), Dst Port: rockwell-cs 
Hypertext Transfer Protocol 


+ 


+ 


+ 


0000 45 00 E. 
0010 00 76 00 06 00 00 40 06 f8 63 cO a8 00 01 cO a8 E ee, Ra 
0020 00 c7 00 50 08 af 03 b5 Oe cb dc d9 cb ae 50 10 N Paiao, (ae ss <= P. 
0030 16 dO 51 94 00 00 48 54 54 50 2f 31 2e 31 20 32 Q...HT TP/1.1 2 


0040 30 30 20 4f 4b Od Oa 43 6f Ge 74 65 Ge 74 2d 54 00 OK..C ontent-T 
0050 79 70 65 3a 20 61 70 70 6c 69 63 61 74 69 6f 6e ype: app lication 
0060 2f 78 2d 6a 61 76 61 73 63 72 69 70 74 Od Oa 43 /x-javas cript..c 
0070 6f 6e 6e 65 63 74 69 6f Ge 3a 20 63 6c 6f 73 65 onnectio n: close 
0080 Od Oa Od Oa 


Na janela inferior, há o conteúdo total do pacote (132 bytes), representado na forma Figura 2.12 


hexadecimal (da posição x'0000' até a posição x'0083'). Cada linha representa 16 bytes Detalhe da camada 
de enlace de dados 


(8 linhas x 16 = 128 + 4 = 132 bytes). Na janela imediatamente acima estão representadas as do pacote 258. 


diversas camadas de protocolos, a saber: 


o Camada física - frame 258 (132 bytes on wire, 132 bytes captured); identifica o quadro 
no arquivo e conta a quantidade de bytes total; 


o Camada de enlace de dados - Ethernet Il, Src: D-Link f8:4c:6b (00:17:9a:f8:4c:6b), Dst: 
AcerNetx_01:d3:06 (00:60:67:01:d3:06); identifica os endereços físicos de origem e destino 


do quadro; em ambos identifica o fabricante da placa de rede pelos 3 primeiros octetos; 
o Camada de rede - Internet Protocol Version 4, Src: 192.168.0.1 (192.168.0.1), Dst: 
192.168.0.199 (192.168.0.199); identifica os endereços de rede IP de origem e destino; 
o Camada de transporte - Transmission Control Protocol, Src Port: http (80), Dst Port: 


2223 (2223), Seg: 1, Ack: 305, Len: 78; identifica o protocolo TCP e as respectivas portas 
TCP que representam as aplicações de cada lado; 


o Camada de aplicação - Hypertext Transfer Protocol; identifica o protocolo da aplicação. 


Cada camada, quando selecionada, faz com que os bytes correspondentes fiquem desta- 
cados na janela inferior. A figura anterior mostra o cabeçalho da camada de enlace de dados 
que tem o tamanho de 14 bytes. Se tivéssemos selecionado a camada física, todo o quadro 
estaria em destaque (132 bytes). As próximas figuras mostram em destaque os dados das 
camadas de rede, transporte e aplicação, respectivamente. 


Na figura seguinte estão destacados os bytes do cabeçalho do protocolo IP (20 bytes). 


No. Time Source Destination Protocol Length Info 
258 7.325574 192.168.0.1 192.168.0.199 HTTP 132 HTTP/1.1 200 OK 





= Frame 258: 132 bytes on wire (1056 bits), 132 bytes captured (1056 bits) 
E Ethernet II, Src: D-Link_f8:4c:6b (00:17:9a:f8:4c:6b), Dst: AcerNetx O1:« 
E Internet Protocol version 4, Src: 192.168.0.1 (192.168.0.1), Dst: 192.16! 





E Transmission Control Protocol, Src Port: http (80), Dst Port: rockwell-c: 











+ Hypertext Transfer Protocol ©0000 
(0000 4 Ei TE sca es 
0010 

0020 [Ms 00 50 08 af 03 b5 Oe cb dc d9 cb ae 5010 [MpP.... ...... 
0030 .Q...HT TP/1. i? 





0040 30 30 20 4f 4b Od Oa 43 6f Ge 74 65 Ge 74 2d 54 00 OK..C ontent-T 
0050 79 70 65 3a 20 61 70 70 6c 69 63 61 74 69 6f 6e ype: app lication 
0060 2f 78 2d 6a 61 76 61 73 63 72 69 70 74 Od Oa 43 /x-javas cript..c 
0070 6f 6e 6e 65 63 74 69 6f Ge 3a 20 63 6c 6f 73 65 onnectio n: close 
0080 Od Oa Od Oa afar lta 


Figura 2.13 Na figura seguinte estão destacados os bytes do cabeçalho do protocolo TCP (20 bytes). 
Detalhe da 
camada de rede 
do pacote 258. 


No. Time Source Destination Protocol Length Info 
258 7.325574 192.168.0.1 192.168.0.199 HTTP 132 HTTP/1.1 200 OK 


Œ Frame 258: 132 bytes on wire (1056 bits), 132 bytes captured (1056 bits) 
= Ethernet II, Src: D-Link f8:4c:6b (00:17:9a:f8:4c:6b), Dst: AcerNetx 01:c 
E Internet Protocol version 4, Src: 192.168.0.1 (192.168.0.1), Dst: 192.16€ 
a Transmission Control Protocol, Src Port: http (80), Dst Port: rockwell-cs 
E 


0000 00 60 67 01 d3 06 00 17 9a f8 4c 6b 08 00 45 00 é Geese ais ERG Es 
0010 00 76 00 06 00 00 40 06 f8 63 cO a8 00 01 cO a8 Eae A 

0020 OO c7 [ETR ER ER ee: (oe ia RETRO 
0030 ig peer mem 48 54 54 50 2f 31 2e 31 20 32 FERE. 

0040 30 30 20 4f 4b Od Oa 43 6f Ge 74 65 Ge 74 2d 54 00 OK. ry ontent-T 
0050 79 70 65 3a 20 61 70 70 6c 69 63 61 74 69 6f Ge ype: app lication 
0060 2f 78 2d 6a 61 76 61 73 63 72 69 70 74 Od Oa 43 /X- -javas cript..c 
0070 6f Ge 6e 65 63 74 69 6f Ge 3a 20 63 Gc 6f 73 65 onnectio n: close 
0080 Od Oa Od Oa PAN 





















Figura 2.14 Finalmente, na figura a seguir aparecem em destaque os bytes correspondentes à men- 
sri da a sagem HTTP, incluindo o cabeçalho e os dados da aplicação. Note que essa mensagem tem o 
e transporte do 
os 258 tamanho de 78 bytes, conforme informado pelo Wireshark, linha da camada de transporte, 
último campo (Len: 78). Observe que, como o protocolo TCP é o único que faz a interface 
com a aplicação, somente ele poderia saber o tamanho da mensagem da aplicação. 
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No. Time Source Destination Protocol Length Info 
258 7.325574 192.168.0.1 192.168.0.199 HTTP 132 HTTP/1.1 200 Ok 


(Œ Frame 258: 132 bytes on wire (1056 bits), 132 bytes captured (1056 bits) 
= Ethernet II, src: D-Link_f8:4c:6b (00:17:9a:f8:4c:6b), Dst: AcerNetx_O1:) 
Œ Internet Protocol Version 4, Src: 192.168.0.1 (192.168.0.1), Dst: 192.16: 
= Transmission Control Protocol, Src Port: http (80), Dst Port: rockwell-c 


m Hypertext Transfer Protocol 














0000 00 60 67 01 d3 06 0017 9a f8 4c 6b 08 00 45 00 a eee Rs Pe 
0010 76 f8 cO a8 00 01 cO MaE Sees 
0020 GZ Oe dc d9 cb ae 50 Sad Pág dadas P. 
0030 do 2 ath fee = 
0040 74 









0050 63 
0060 69 
0070 20 
0080 = 


ype: app licatio 
/x-javas cript..c 
onnectio n: close 





Figura 2.15 
Detalhe da camada 
de aplicação do 


Verificação final do tamanho total do quadro: 


14 bytes (cabeçalho Ethernet) + 20 bytes (cabeçalho IP) + 20 bytes (cabeçalho TCP) + 78 bytes 





pacote 258. 

(mensagem da aplicação) = 132 bytes. 
Desencapsulamento 
Na recepção, ocorre o processo inverso ao encapsulamento. Conforme mostra a Figura 2.16, 
cada unidade de dados sobe na pilha de protocolos até que os dados sejam efetivamente 
entregues ao programa de aplicação. Cada camada trata as suas informações de controle, 
realizando funções específicas de acordo com a informação contida no cabeçalho. 

Aplicação FTP nas SMTP DNS ane SNMP 

Transporte TCP Porta UDP Porta 

Rede P 

Protocol 
E ceeecensecenecenseceneetensetenassenes: Figura 2.16 


7 Processo de 
Interface de rede desencapsulamento 
Srece TCP/IP. 
Em seguida, o cabeçalho da unidade de dados é removido e apenas o campo de dados é 
entregue à camada imediatamente superior. Consequentemente, o campo de dados de uma 


dada camada representa a unidade de dados (cabeçalho somado aos dados propriamente 
ditos) da camada imediatamente superior. Esse processo é denominado desencapsulamento. 


Vamos acompanhar os detalhes desse processo. O processo de desencapsulamento começa 
com a recepção de um quadro da rede física. A camada de interface de rede realiza o trata- 
mento adequado do quadro, efetuando, por exemplo, a detecção de erros de transmissão. 
Assim, após realizar suas funções, a camada de interface de rede entrega o respectivo data- 


grama diretamente ao protocolo IP, implementado no sistema operacional. 


Caso a estação em questão seja o destino final do datagrama, o protocolo IP entrega o con- 
teúdo do campo de dados do datagrama à camada de transporte ou ao protocolo ICMP. 
Para tal, o campo Protocol (protocolo) do datagrama é avaliado para identificar se o conteúdo 
é uma mensagem ICMP, um segmento TCP ou um datagrama UDP, e, depois, realizar a entrega 
ao protocolo correspondente (ICMP, TCP ou UDP, respectivamente). 


Por fim, baseados nos campos do cabeçalho que identificam as portas das aplicações comuni- 
cantes, os protocolos TCP e UDP extraem a mensagem encapsulada e entregam diretamente 
ao programa de aplicação de destino. Já no caso de uma mensagem ICMP, a unidade de dados 
já atingiu o destino final e, assim, não sobe mais na pilha de protocolos. 


O processo de desencapsulamento ocorre tanto na estação de destino quanto nos vários 
roteadores intermediários. No entanto, como os datagramas IP devem ser encaminhados 
adiante nos roteadores intermediários, a unidade de dados encapsulada no datagrama IP 
não sobe na pilha de protocolos. Em vez disso, o datagrama IP passa por um novo processo 
de encapsulamento. Em conjunto, os processos de encapsulamento e desencapsulamento 
asseguram a correta comunicação entre entidades pares de uma dada camada. Ou seja, a 
entidade de destino sempre recebe uma cópia idêntica da unidade de dados enviada pela 
entidade de origem. 


Interação dos protocolos 


Para alcançar uma determinada estação de destino, datagramas IP devem (se possível) ser 
roteados através de diversos roteadores e redes intermediárias. A Figura 2.17 ilustra uma 


inter-rede TCP/IP que será utilizada para a análise do processo de interação dos protocolos. 


m 
=à 


Ag 


Protocolo SNMP SNMP 


n 
Zz 
zZ 
v 


Protocolo UDP 


R1 sie R2 >< 


A da A 


DRIVER DRIVER | DRIVER DRIVER | DRIVER DRIVER 
<a> N 


A > ™ A > A 


GD & & 


Figura 2.17 Essa inter-rede é composta por três redes físicas distintas (N1, N2 e N3), interconectadas por 
Interação dos 
protocolos TCP/IP. 


ARH et dy 
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dois roteadores (R1 e R2). Vamos supor que a estação E1 deseje transmitir uma mensagem 
do protocolo de aplicação SNMP para a estação E2 usando o protocolo UDP como meca- 


nismo de transporte. As seguintes etapas podem ser observadas na inter-rede analisada: 


[en] 
to 


Ñ Arquitetura e Protocolos de Rede TCP-IP 


a 
© 


a Logo após montar uma mensagem SNMP, o programa de aplicação na estação E1 solicita 
ao sistema operacional que envie a mensagem usando o protocolo UDP, tendo como 


destino a estação E2. 


a O sistema operacional monta um datagrama UDP, incluindo no cabeçalho os identifica- 
dores das portas associadas às aplicações de origem e destino, e encapsula a mensagem 
SNMP no campo de dados. 


o Em seguida o sistema operacional encapsula o datagrama UDP em um datagrama IP, 
incluindo no cabeçalho os endereços IP das estações de origem e destino, e insere o 
datagrama UDP no campo de dados. Além disso, o cabeçalho do datagrama IP sinaliza no 


campo Protocol que transporta um datagrama UDP. 


a Baseado nas informações de roteamento mantidas na estação E1, o sistema operacional 
roteia o datagrama IP para o roteador R1. Nesse processo, o datagrama IP é encapsulado 
em um quadro da rede física N1 e, então, transmitido pela camada de interface de rede. 


a Após receber o quadro da rede física N1, a camada de interface de rede associada à rede 


N1 do roteador R1 extrai o datagrama IP e o decodifica. 


a Ao observar o endereço IP de destino no cabeçalho do datagrama, o roteador R1 percebe 
que esse datagrama não é endereçado a ele e a nenhuma estação da rede N2. 


a O roteador R1 encaminha o datagrama para o roteador R2, baseado nas informações de 
roteamento mantidas no roteador R1. Nesse processo, o datagrama IP é encapsulado 
em um quadro da rede física N2, e então transmitido pela camada de interface de rede 


associada a essa rede. 


o Quando recebe o quadro da rede física N2, a camada de interface de rede associada a 
rede N2 do roteador R2 extrai o datagrama IP e o decodifica. Pelo endereço IP de destino, 
informado no cabeçalho do datagrama, o roteador também percebe que o roteador R2 


não é o destino final desse datagrama. 


a Com base nas informações de roteamento mantidas no roteador R2, ele descobre que 
pode enviar o datagrama IP diretamente para a estação de destino. Assim, o datagrama 
IP é encapsulado em um quadro da rede física N3 e então transmitido pela camada de 


interface de rede associada a essa rede. 


a Ao receber o quadro, a camada de interface de rede da estação E2 extrai o datagrama IP 
e o decodifica. Como o endereço IP de destino (informado no cabeçalho do datagrama) 
é o da própria estação E2, o sistema operacional percebe que o datagrama é destinado 


àquela estação. 


a O sistema operacional avalia o campo Protocol do datagrama IP e descobre que um 
datagrama UDP é transportado no campo de dados. O sistema operacional extrai o 
datagrama UDP. 


o Em seguida, o sistema operacional extrai do datagrama UDP a mensagem SNMP ea 
entrega ao programa de aplicação destino após identificar a porta associada a esta 


aplicação. Isso encerra a interação dos vários protocolos. 


Em síntese, os sistemas operacionais utilizam os protocolos das várias camadas para 
montar, enviar, receber e processar unidades de dados de suas respectivas camadas. Por 
exemplo, o sistema operacional utiliza o protocolo IP para montar datagramas e solicitar 
que sejam enviados à camada de interface de rede. Além disso, recebe e processa os data- 
gramas IP extraídos pela camada de interface de rede. 


Durante o envio de datagramas IP, cada datagrama pode ser roteado diretamente para a 
estação de destino ou para algum roteador intermediário. Por outro lado, na recepção de 
datagramas IP, se a estação for o destino, o datagrama recebido é localmente repassado à 
camada de transporte. Caso contrário, o datagrama recebido é roteado para a estação de 
destino ou para outro roteador intermediário. As camadas de aplicação e transporte sempre 
usam protocolos fim-a-fim. Ou seja, tais protocolos transportam unidades de dados direta- 
mente entre as estações de origem e destino. Portanto, na figura, apenas as estações E1 e 
E2 apresentam as camadas de aplicação e transporte. 


As camadas inter-rede e interface de rede adotam protocolos que permitem a troca de 
unidades de dados apenas entre equipamentos conectados a uma mesma rede física. Dessa 
forma, as camadas inter-rede e interface de rede estão presentes nas estações comuni- 
cantes e nos vários roteadores intermediários. Pelo fato de conectar várias redes físicas, 
cada roteador pode possuir diversas implementações da camada de interface de rede; cada 
uma delas específica para um determinado tipo de rede física. Por exemplo, uma conexão 

a uma rede local através de uma interface Fast Ethernet, e uma conexão de longa distância 
através de uma interface POS. Entretanto, roteadores possuem apenas uma única imple- 
mentação da camada de rede, porque o protocolo IP é adotado em toda a inter-rede para 


garantir a interoperabilidade dos vários dispositivos. 


Endereços físicos e lógicos 


CJ 
Endereço físico: 


a É o endereço da estação do usuário na rede física. 

a Somente identifica o equipamento, não a rede. 

a Não é roteável entre as redes físicas. 

a Exemplo: endereço MAC Ethernet. 

Endereço lógico: 

a Identifica a rede física e a estação do usuário na rede. 


a Éroteável entre as redes físicas. 





a Exemplo: endereço IP. 


Existem inúmeras diferenças entre endereço físico e endereço lógico, das quais destacamos: 
ao Endereço físico está associado à camada de enlace, servindo para identificar somente o 
equipamento, sem considerar a rede em que ele se encontra. 


a Do ponto de vista do endereçamento físico, todos os equipamentos pertencem à 
mesma rede. 


a Endereço lógico identifica a rede na qual o equipamento se encontra e também o próprio 


equipamento dentro da rede. 


a O endereço lógico permite que os equipamentos estejam situados em redes diferentes. 
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Comparacao das arquiteturas TCP/IP e OSI 


A figura seguinte compara a pilha de protocolos TCP/IP com o modelo OSI de referência: 


OSI TCP/IP 


Apresentação Aplicação 


Transporte Transporte 


Enlace de dados 


Interface 


Física 





ao As duas camadas inferiores podem ser chamadas de camadas de interface de redes. 
o Acamada de rede é chamada de camada internet, no modelo TCP/IP. 


a Ostermos pacote (packet) e datagrama (datagram) são praticamente intercambiáveis. 
Entretanto, um datagrama IP é uma unidade de transmissão fim-a-fim da camada de rede 
(antes da fragmentação e depois da remontagem), enquanto um pacote é uma unidade 
de dados (PDU) passada entre as camadas de rede e de enlace de dados. Um pacote pode 


conter um datagrama completo ou “pedaços” menores a serem transmitidos (fragmentos). 


a Acamada de transporte é funcionalmente similar nos dois modelos. 


de aplicação na arquitetura TCP/IP. 


fins acadêmicos. 


As camadas de sessão, apresentação e aplicação do modelo OSI correspondem à camada 


O modelo TCP/IP é real e usado na prática, enquanto o modelo OSI é mais utilizado para 


Figura 2.18 

Pilha de proto- 
colos TCP/IP versus 
Modelo OSI. 





Figura 2.19 
Opções de captura 
de pacotes do 
Wireshark. 





=F Roteiro de Atividades 2 


Atividade 2.1 - Captura de pacotes 


1. Vamos ativar o Wireshark, como fizemos no capítulo anterior, só que desta vez para confi- 


gurar um filtro de captura. 


Na tela inicial do Wireshark, em vez de selecionar o botão “Start”, vamos selecionar o botão 
“Options” na interface de rede local. Teremos então a tela a seguir. Na janela “Capture Filter”, 
digite a palavra host e seu endereço IP, conforme mostra a figura. Este é um exemplo de 


filtro de captura. 


™ Wireshark: Capture Options 
Capture 
Interface: (Local ¥ | | Broadcom NetXtreme Gigabit Ethernet Driver (Microsoft's Packet Sd ¥ 
IP address: 200. 130.26.4 
Link-layer header type: [Ethernet v 
Capture packets in promiscuous = 
C] Capture packets in pcap-ng format 


ps frabi Buffer size: | 1 > megabyte(s) 
[C] Limit each packet to | 


host 200.130.254 J 


Capture File(s) Display Options 


File: | [V] Update list of packets in real time 


C] Use multiple files = 
[v] Automatic scrolling in live capture 


[V] Hide capture info dialog 





Name Resolution 


Stop Capture ... |V] Enable MAC name resolution 


[C] Enable network name resolution 








[V] Enable transport name resolution 


Em seguida, clique em “Start” para iniciar a captura. Porém, serão capturados somente os 


pacotes que contêm o endereço IP especificado. Os demais pacotes IP serão descartados. 


2. Vamos agora executar uma simples captura de pacotes, navegando no site: http://esr.rnp.br 


Aguarde até que toda a página do site tenha sido carregada, feche a janela do navegador, 
volte para a janela do Wireshark (que ficou aberta) e só então termine a captura de pacotes 
clicando no quarto ícone da esquerda para a direita da barra de ferramentas (Stop the 
running live capture). A janela de captura do Wireshark deve ser semelhante à mostrada na 


figura a seguir, onde está destacado o quadro 251 (tela parcial). 
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No. Time Source Destination Protocol Length Info 


251 4.162664 200.130.26.4 173.194.27.39 TCP 62 ftranhc > http [SYN] 

252 4.190640 173.194.27.39 200.130. 26.4 TCP 62 http > ftranhc [SYN, V 
253 4.190672 200.130.26.4 173.194.27.39 TCP 54 ftranhc > http [Ack] : 
254 4.191093 200.130.26.4 173.194.27.39 HTTP 333 GET /edgedl/update2/1. 
255 4.218975 173.194. 27.39 200.130. 26.4 TCP 60 http > ftranhc [ACK] : 
256 4.220161 173.194.27.39 200.130. 26.4 TCP 456 [TCP segment of a rea: 
257 4.220385 173.194.27.39 200.130.26.4 TCP 1314 [TCP segment of a rea: 
258 4.220470 200.130. 26.4 173.194.27.39 TCP 54 ftranhc > http [Ack] : 
259 4.220476 173.194.27.39 200.130. 26.4 TCP 1314 [TCP segment of a rea: 
260 4.220558 173.194. 27.39 200.130. 26.4 TCP 1314 [TCP segment of a rea: 
261 4.220615 200.130. 26.4 173.194.27.39 TCP 54 ftranhc > http [Ack] : 
262 4.220670 173.194.27.39 200.130. 26.4 TCP 1314 [TCP segment of a rea: 
263 4.220721 173.194.27.39 200.130.26.4 TCP 1314 [TCP segment of a rea: 


aca A ATNA “an 49M Ne A a77 ana 99 SA won CA Fenanbe ~ bern Part u 
Œ Frame 251: 62 bytes on wire (496 bits), 62 bytes captured (496 bits) 
Œ Ethernet II, Src: Dell eO:cc:45 (00:18:8b:e0:cc:45), Dst: ExtremeN_41:24:f0 (00:04:96:41:24:f0) 
E Internet Protocol Version 4, Src: 200.130.26.4 (200.130.26.4), Dst: 173.194.27.39 (173.194. 27.39) 
+ Transmission Control Protocol, src Port: ftranhc (1105), Dst Port: http (80), Seq: 0, Len: O 


Note a grande quantidade de pacotes trocada entre 0 seu computador (IP: 200.130.26.4) eo Figura 2.20 
Quadro 251 


ee = : . capturado pelo 
E fácil perceber que uma navegação demorada vai gerar uma grande quantidade de pacotes Wireshark. 


servidor do site www.esr.rnp.br (IP: 173.194.27.39), apenas para abrir a pagina inicial do site. 


capturados, podendo dificultar a análise detalhada de um volume considerável de dados. 


Este exemplo de captura de pacotes pode ser aplicado a qualquer site e também para outras 


aplicações, como e-mail e downloads. 


Atividade 2.2 —- Caminhos de rede 


Considere a rede da Figura 2.21: 


Figura 2.21 
Rede da 
Atividade 2.2. 





1. Identifique um possível caminho a ser seguido por pacotes enviados da estação E2 para 
a estação E8. Adote uma narrativa semelhante àquela apresentada no tópico “modelo de 


interconexão”, em que essa figura é discutida. 











2. Considere que existe uma conexão entre o roteador R2 e a rede N1. Essa nova conexão 
exerce alguma influência na sua resposta anterior? Explique. 














Atividade 2.3 — Estações multihomed 


Na mesma rede da figura anterior, considere que a estação E9 possui uma conexão com a 
rede N5 (como já mostrado na figura anterior) e que uma nova conexão com a rede N4 foi 


acrescentada (não ilustrada na figura anterior). 


1. É correto afirmar que a estação E9 é multihomed? Explique. 














2. A existência de múltiplas conexões assegura que a estação E9 opere como um roteador? 
Em caso afirmativo, apresente a justificativa. 














3. Se a estação E9 não opera como um roteador, existe alguma forma de transformar essa 


estação em roteador? Explique. 














Atividade 2.4 - Modelo OSI 


Um fabricante de equipamentos de rede lhe enviou um catálogo de produtos. Um trecho do 


catálogo é transcrito abaixo: 
Switch-Router Ethernet XYZ Super-Plus 
Recursos L2: até 8000 endereços 
Recursos L3: 20000 rotas 


Consulte-nos também sobre a linha Mega Power, com a tecnologia de inspeção profunda de 


pacotes que permite a criação de filtros L7. 


Você sabe que os fabricantes costumam usar o modelo ISO/OSI como referência. Explique 
para alguém que só conheça a arquitetura TCP/IP o que o anúncio acima quer dizer. 
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Figura 3.1 
Endereço IPv4. 


Endereçamento IP (parte 1) 


Apresentar as técnicas de resolução e atribuição automática de endereços, 
bem como os mecanismos de entrega adotados na arquitetura TCP/IP. 


Endereçamento IPv4 e cálculo de sub-redes por diversos métodos. 





Endereço IPv4 


(a 
O endereço IPv4 tem o objetivo de identificar, de forma única e individual, cada disposi- 
tivo da inter-rede TCP/IP. Também denominado de endereço internet. Representação: 


o Número inteiro de 32 bits. 


o Permite até 23 endereços. 


Os usuários enxergam a internet como uma rede virtual única, na qual todos os dispositivos 
estão conectados. Para possibilitar essa conexão, um mecanismo de endereçamento uni- 
versal deve ser adotado, permitindo a identificação individual e única de cada dispositivo. 
Em redes TCP/IP, essa identificação é realizada por meio de endereços IP, também denomi- 


nados endereços internet. 


Os endereços IP podem ser de dois tipos: IPv4 e IPv6. Trataremos primeiro dos endereços IPv4, 
que foram concebidos primeiro. Depois veremos o IPv6 e o por quê da sua existência. Endereços 
IPv4 são números inteiros de 32 bits. Portanto, existe um total de 232 endereços possíveis. 


0 31 


11000000 10101000 00001010 00000001 


Notação decimal 


Representação por 4 números decimais separados por pontos, em que cada número a 


decimal está associado a um determinado octeto do endereço. | 


Para facilitar a manipulação, os endereços IPv4 são normalmente escritos com uma notação 
decimal pontuada, denominada dotted-decimal notation. Cada número decimal está asso- 
ciado a um determinado octeto do endereço e, portanto, varia entre 0 e 255. A figura 


seguinte apresenta as notações binária e decimal de um endereço IPv4. 


o 
j=) 
= 
o 
ig?) 
= 
jo) 
n 
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31 


0 
11000000 10101000 00001010 00000001 


Figura 3.2 

Notação decimal 

pontuada do 
192 . 168 . 10 . 1 endereço IPv4. 


Atribuição de endereços 


ao Endereços IPv4 não são atribuídos às estações e roteadores. 

o Endereços IPv4 são atribuídos as interfaces de estações e roteadores. 

a Cada interface de estações e roteadores deve possuir um endereço IPv4. 
o Estações multihomed e roteadores possuem diversos endereços IPv4. 


Endereços IPv4 não são atribuídos diretamente às estações e roteadores, mas às interfaces 
de rede desses dispositivos. Dessa forma, cada interface de estações e roteadores deve 
possuir um endereço IPv4 único. É fácil, portanto, concluir que estações multihomed e rotea- 


dores possuem múltiplos endereços IPv4. 


Hierarquia de endereçamento 


Em vez de utilizar uma numeração puramente sequencial, os endereços IPv4 adotam uma 
estrutura hierárquica que identifica as redes físicas e as estações (interfaces) nessas redes. 
A razão dessa estruturação hierárquica é realizar o roteamento baseado em redes, em vez 
de baseado em estações. Essa abordagem reduz sensivelmente a quantidade de informa- 
ções de roteamento e o torna mais eficiente. A Figura 3.3 ilustra a estrutura hierárquica dos 


endereços IPv4. 


0 31 


— E 7 Figura 3.3 
Identificador de rede Identificador de estação Hierarquia de 


endereçamento. 


O roteamento é baseado em redes, portanto, as informações de roteamento apontam para 
as redes, e não para as estações individuais. 


à 


Para representar essa hierarquia, todo endereço IPv4 é dividido em duas partes: 


o Identificador de rede - comumente denominado prefixo de rede, identifica a rede de 
forma única e individual. 


o Identificador de estação - identifica a estação (interface) dentro da rede de forma 


única e individual. 


Regras de atribuição de endereços 


CJ 
o Diferentes prefixos de rede devem ser adotados para diferentes redes físicas. 

a Um único prefixo de rede deve ser compartilhado por interfaces de uma rede física. 

a Um único identificador de estação deve ser atribuído a cada interface de uma rede física. 


Figura 3.4 
Exemplo 

de atribuição 
de endereços. 


Na atribuição de endereços às interfaces de estações e roteadores, as seguintes regras 
devem ser seguidas: 


1. Diferentes prefixos de rede devem ser adotados para diferentes redes físicas. Como os 
roteadores na inter-rede encaminham pacotes entre as redes físicas, é preciso que eles 
saibam distinguir umas das outras, através do prefixo de rede. Assim como no correio 
postal, cada cidade tem que ter um identificador diferente (CEP), para possibilitar o enca- 


minhamento de cartas de uma cidade para outra. 


2. Um único prefixo de rede deve ser compartilhado pelas interfaces conectadas a uma mesma 
rede física. Se as interfaces pertencem a uma mesma rede física, elas devem usar o mesmo 
prefixo de rede atribuído à rede física, para que possam receber pacotes vindos de outras 
redes físicas ou de outra estação da mesma rede onde elas estão. Assim como no correio 


postal, cada bairro que pertence a uma cidade precisa ter o nome da cidade no seu endereço. 


3. Um único identificador de estação deve ser atribuído a cada interface conectada a uma 
determinada rede física. Não pode haver duas interfaces, dentro da mesma rede física, 
com o mesmo identificador de estação. É como se numa rua existissem duas casas com o 


mesmo número. 


192.168.10.3 200.10.1.3 





192.168.10.2 200.10.1.2 


Por exemplo, observe na Figura 3.4, onde todas as máscaras de rede são /24, que todas as 
interfaces conectadas às redes N1 e N2 compartilham prefixos de redes que identificam 
suas respectivas redes físicas. Isso significa que as estações (E1 e E2) e o roteador (R1) 
compartilham o prefixo 192.168.10 da rede N1, enquanto as estações (E3 e E4) e o roteador 
(R1) compartilham o prefixo 200.10.1 da rede N2. 


Interfaces conectadas a diferentes redes físicas podem possuir os mesmos identificadores 
de estação, pois seus prefixos de rede são diferentes e asseguram a unicidade de ende- 
reços. Por exemplo, na rede N1, as estações (E1 e E2) e o roteador (R1) possuem os identifica- 
dores de estação 1,2 e 3, respectivamente. Já na rede N2, as estações (E3 e E4) e o roteador 
(R1) possuem, também, os identificadores de estação 1,2 e 3, respectivamente. 


Classes de endereços 


à 


a Endereços classe A. 
a Endereços classe B. 
a Endereços classe C. 


a Endereços classe D. 





oa Endereços classe E. 
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Em relação à capacidade, permitem a configuração de um variado número de redes com 


diferentes tamanhos. | 


Para acomodar diferentes tamanhos de redes físicas, o espaço de endereços IPv4 é dividido 
em cinco classes de endereços, denominadas classes A, B, C, D e E. Cada classe adota uma 


posição diferente para delimitar o prefixo de rede e o identificador de estação. 


0 1 7 8 31 
0 2 15 16 31 
0 3 23 24 31 


Figura 3.5 


endereços IPv4, 





A Figura 3.5 ilustra as classes de endereços IPv4, cuja distinção é realizada por um código 


fixo associado a cada classe nos primeiros bits do octeto mais significativo. 


o Endereços classe A - os 8 primeiros bits identificam a rede e os outros 24 bits identi- 
ficam a estação. Assim, podemos concluir que o total de redes classe A é de 2’ (primeiro 
bit do prefixo de rede sempre igual a 0), com até 274 estações em cada rede. 


o Endereços classe B - os 16 primeiros bits representam o prefixo de rede e os outros 16 bits 
representam o identificador da estação. Nesse caso, o total de redes classe B é de 2 
(dois primeiros bits do prefixo de rede fixados em 10), com até 2'6 estações em cada rede. 


o Endereços classe C - possuem 24 bits que identificam a rede e apenas 8 bits que identificam 
a estação. Assim, a quantidade de redes classe C é de, no máximo, 2?! (três primeiros bits do 


prefixo de rede fixados em 110), com até 2º estações em cada rede. 


Observe que as classes A, Be C permitem a configuração de um variado número de redes 
com diferentes tamanhos: 


a Endereços classe A suportam poucas redes, mas cada uma delas pode ser gigantesca. 


a Endereços classe B suportam um número mediano de redes, com tamanho 


relativamente grande. 
ao Endereços classe C suportam um grande número de pequenas redes. 


a Endereços classe D são usados para suportar endereçamento multicast, em que cada 
endereço é associado a um grupo de estações. Neste caso, pacotes destinados a um 
determinado endereço multicast são entregues às estações que pertencem ao respectivo 
grupo. O conjunto composto pelos 28 bits de um endereço classe D é denominado iden- 
tificador de grupo multicast. Ao contrário das classes A, Be C, endereços multicast não 
possuem qualquer hierarquia. Na prática, endereçamento multicast pode ser utilizado 
por aplicações interativas de grupo - por exemplo, videoconferência - ou como meca- 
nismo para identificar serviços em uma rede. 


Figura 3.6 
Capacidade de 
redes e estações 
de cada classe de 
endereços IPv4. 


Figura 3.7 
Espaço de 
endereçamento. 


Figura 3.8 
Endereços especiais. 


Figura 3.9 
Convenção para 
endereços de rede. 


ao Endereços classe E não são utilizados na prática, sendo reservados para uso experimental. 


Classe Número de redes Número de estações 
A : 27 : 224 
B É pé ne 
c am iz 


Baseado nas classes de endereços IPv4 mostradas na Figura 3.5, podemos deduzir as faixas 
de endereços IPv4 de cada classe, ou seja, o espaço de endereçamento total por classe, 
conforme mostrado na tabela seguinte. 


Classe Intervalos de endereços 
A 0.0.0.0 - 127.255.255.255 
B 128.0.0.0 - 191.255.255.255 
C 7 192.0.0.0 - 223.255.255.255 
D É 224.0.0.0 - 239.255.255.255 
E É 240.0.0.0 - 255.255.255.255 


Endereços especiais 


Considerando o espaço de endereços das classes A, Be C, vários desses endereços são 
reservados para determinadas finalidades: identificação de rede, broadcast, endereços 


privados, identificação de rota default e loopback. 


Endereço de rede Prefixo de rede 


Broadcast direto Prefixo de rede 


= 
mi 
Es = 
= = 


Broadcast limitado 


Rota default 


x 
x 


Loopback 127 


Endereços de rede e broadcast 


Além de serem utilizados para identificar estações (interfaces de estações e roteadores) 
de uma rede, os endereços IPv4 servem para referenciar as próprias redes. Por isso, por 
convenção, qualquer endereço classe A, B ou C, cujo identificador de estação possua todos 
os bits iguais a 0, é reservado para endereçar a própria rede, denominando-se, então, 
endereço de rede. Assim, o identificador de estação com todos os bits iguais a O nunca é 
atribuído a uma interface. A tabela seguinte ilustra a convenção para endereços de rede. 


Classe Prefixo de rede Endereço de rede 
A 10 : 10.0.0.0 

B 172.16 172.16.0.0 

G | 192.168.10 192.168.10.0 
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Endereços de rede nunca são usados diretamente nos datagramas IPv4. Entretanto, como 
o roteamento na arquitetura TCP/IP é baseado em redes, em vez de estações, os endereços 
de rede são largamente adotados para manter as informações de roteamento que apontam 
para as respectivas redes. Uma vez que cada rede física possui um endereço de rede parti- 
cular, o endereçamento IP adota o conceito de broadcast direto. 


Para suportar o conceito de broadcast direto, o endereçamento IPv4 reserva um endereço 
especial em cada rede. Por convenção, qualquer endereço classe A, B, ou C, cujo identificador de 
estação possua todos os bits iguais a 1, é reservado para representar o endereço de broadcast 
direto. Assim, o identificador de estação com todos os bits iguais a 1 nunca deve ser atribuído a 


uma interface. A tabela seguinte ilustra a convenção para endereços de broadcast direto. 


broadcast direto. 


Classe Endereço de rede Endereço de broadcast direto 

A É 10.0.0.0 É 10.255.255.255 
i : Figura 3.10 

B : 172.16.0.0 : 172.16.255.255 Convenção para 
: i endereços de 

€ : 192.168.10.0 : 192.168.10.255 


Ao contrário de endereços de rede, que nunca são usados diretamente nos datagramas 
IPv4, endereços de broadcast direto podem ser usados em datagramas, permitindo ao 


roteador de entrada da rede destino realizar o broadcast do datagrama naquela rede. 


Além do conceito de broadcast direto, o endereçamento IPv4 também suporta o conceito 
de broadcast limitado, que, similarmente, permite o envio de datagramas IPv4 para todas 
as estações (interfaces de estações e roteadores) de uma determinada rede. No entanto, 
ao contrário do broadcast direto, que permite o envio a partir de qualquer estação da 
inter-rede TCP/IP, o broadcast limitado permite o envio apenas a partir de uma estação 
localizada na própria rede destino. Ou seja, somente uma estação da própria rede pode 
realizar o broadcast limitado para aquela rede. Na prática, o broadcast limitado é geral- 


mente usado durante procedimentos de identificação de serviços em uma rede. 


Para suportar o conceito de broadcast limitado, o endereçamento IPv4 reserva um endereço 
especial que, por convenção, é composto de 32 bits iguais a 1. Assim, o endereço 255.255.255.255 
é reservado para representar o endereço de broadcast limitado. Da mesma forma que endereços 


de broadcast direto, o endereço de broadcast limitado pode ser usado em datagramas IP. 


® 
Exercício de fixação iG 


Classes de endereçamento 
Máscara de rede 


Considere que os seguintes endereços foram usados para configurar interfaces de um rote- padrão 


ador: 200.150.10.10, 20.1.1.10 e 150.10.1.100. Cada classe de endereço 
tem uma máscara 


padrão indicando os 
octetos que identificam 
a rede, e os octetos que 
identificam a estação. Os 
octetos de rede são iden- 
tificados pelo decimal 


255 e os de estação pelo 
2. Qual é a máscara de rede padrão de cada endereço? decimal 0 (zero). 


1. Qual é a classe de endereçamento de cada um deles? 




















Figura 3.11 


Espaço de endere- 
çamento e ende- 
reços permitidos. 


Rota default 


Rota adotada quando nenhuma outra rota da tabela de roteamento está associada ao 
endereço de rede do destino do datagrama. O conceito de rota default é fundamental para 
minimizar a quantidade de informações de roteamento e tornar mais eficiente o roteamento 
em roteadores e estações. Para suportar o conceito de rota default, o endereçamento IPv4 
reserva um endereço especial que, por convenção, é composto de 32 bits iguais a 0, con- 
forme ilustrado na Figura 3.8. Logo, o endereço 0.0.0.0 é reservado para representar uma 


rota default e, portanto, não pode ser usado para uma rede. 
Interface e endereço de loopback 


Para viabilizar um mecanismo de teste local de protocolos e serviços, o conceito de inter- 
face de loopback é suportado por diversas implementações. Como ilustrado na Figura 3.8, 
o endereço de rede classe A 127.0.0.0 é reservado para a interface de loopback e, portanto, 
não pode ser usado para uma rede. Na prática, geralmente, apenas o endereço 127.0.0.1 é 
usado para identificar essa interface. Assim, qualquer datagrama IP destinado ao endereço 
127.0.0.1 não é efetivamente enviado na rede física, mas retorna para a própria estação. 
Consequentemente, é impossível enviar um datagrama IP para o endereço de loopback de 
outra estação. 


Espaço de endereçamento e endereços permitidos 


a Espaço de endereçamento: conjunto de endereços que compartilham um mesmo 
prefixo de rede. | 


ao Endereços permitidos: conjunto de endereços que podem ser atribuídos as interfaces. 


Considerando um endereço classe A, B ou C para cada prefixo de rede, o espaço de endere- 
çamento é composto por todos aqueles que podem ser expressos por meio da variação do 
identificador da estação, conforme mostra a tabela seguinte. 


Classe Prefixo de Espaço de endereçamento Endereços permitidos 
rede 
A 10 10.0.0.0 - 10.255.255.255 10.0.0.1 - 10.255.255.254 
B 172.16 172.16.0.0 - 172.16.255.255 172.16.0.1 - 172.16.255.254 
C 2 192.168.10 | 192.168.10.0 - 192.168.10.255 | 192.168.10.1 - 192.168.10.254 


Considerando o espaço de endereçamento das classes A, Be C, os endereços permitidos são 
todos aqueles que podem ser atribuídos às interfaces de estações e roteadores. Portanto, os 
endereços permitidos compreendem todo o espaço de endereçamento, exceto o primeiro 


(endereço de rede) e o último (endereço de broadcast direto), conforme a Figura 3.11. 


Máscara de rede 

Seu objetivo é delimitar a posição do prefixo de rede e do identificador de estação. 
Representação por padrão de 32 bits: 

ao Possui bits 1 no prefixo de rede. 


a Possui bits O no identificador de estação. 
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As classes de endereços adotam diferentes posições para delimitar o prefixo de rede e o iden- 
tificador de estação. Além dos primeiros bits do prefixo de rede, o endereçamento IP adota o 
conceito de máscara de rede para permitir que cada estação conheça o número de bits que 
identifica a rede física e a estação. A Figura 3.12 ilustra a estrutura de uma máscara de rede. 


Figura 3.12 
Máscara de rede. 


(T+ ME 


Notação decimal: 

a Representada por 4 números decimais separados por pontos. 

a Cada número decimal está associado a um determinado byte da máscara. 
Notação de contagem de bits: 


a Representada por um número inteiro que indica a quantidade de bits 1 da máscara. 


Para facilitar a manipulação, máscaras de rede podem ser escritas por meio do uso da 
notação decimal (dotted-decimal notation) ou contagem de bits (bit count). Na notação 
decimal com pontos, de forma similar ao endereço IP, a máscara é representada por quatro 
números decimais, separados por pontos. Cada número decimal está associado a um deter- 


minado byte da máscara e, portanto, varia entre O e 255. 


Na notação de contagem de bits, a máscara é simplesmente representada por um número 
inteiro, precedido por uma barra (/) que sinaliza a quantidade de bits 1 que compõem a máscara. 


A Figura 3.13 ilustra um exemplo de endereço IP e respectiva máscara de rede nas notações 
decimal e contagem de bits. 


11000000 10101000 00001010 00000001 Endereço IP 
11111111 11111111 11111111 00000000 Mascara de rede Figura 3.13 


Exemplo de ende- 
192.168.10.1 255.255.255.0 reço IP e máscara 


192.168.10.1/24 de rede. 


Considerando que os endereços de rede classe A, Be C possuem 8, 16 e 24 bits no prefixo 
de rede, as máscaras 255.0.0.0 (/8), 255.255.0.0 (/16) e 255.255.255.0 (/24) são denominadas 


máscaras default para essas classes de endereços, respectivamente. 


® 
Exercício de fixação 2 _G 


Formatos de representação Notação de 


F ; > . e . contagem de bits 
Ao avaliar a configuração de uma interface de rede, o administrador descobriu qureessar ttre ance 
Indica quantos bits 1 


existem na mascara 
esse endereço IP e essa máscara. Apresente o endereço IP e a mascara usando a notação de rede em binário. 
Exemplo: 255 equivale 
a MINA. 


interface possui o endereço 200.10.192.16 e a máscara 255.255.255.0. Escreva em binário 


de contagem de bits. 








Figura 3.14 
Endereços físicos e 
endereços lógicos. 


Resolução de endereços 


o Problema: datagramas adotam endereços IP e quadros das redes físicas adotam a 
endereços físicos. 
o Solução: mapeamento de endereços IP para endereços físicos. 


A arquitetura TCP/IP suporta uma visão de rede virtual única, porque assume que todas as 
estações adotam endereços IP. Assim, datagramas IP sempre transportam os endereços 

IP das estações de origem e destino. No entanto, as diferentes tecnologias de redes físicas 
possuem seus próprios esquemas de endereçamento. Por exemplo, redes Ethernet adotam 
endereços físicos de 48 bits (MAC Address). 





Datagrama 





Quadro 


Endereços físicos não possuem qualquer relação de tamanho ou valor com endereços IP. 
Assim, cada interface de estações e roteadores deve possuir dois endereços: 


o Endereço físico - endereço adotado pelos protocolos da camada de enlace da arquitetura 
OSI e da camada de interface de rede da arquitetura TCP/IP. Gravado, geralmente, pelo fabri- 


cante na placa de rede, embora algumas tecnologias de rede permitam a configuração direta. 
o Endereço IP - endereço lógico atribuído localmente pelo administrador. 


Quando um quadro é transmitido de uma estação para outra na rede física, os endereços físicos 
de origem e destino são também informados no quadro. Os drivers de dispositivo associados 
as interfaces físicas nunca avaliam diretamente o endereço IP de destino transportado no data- 
grama IP, mas apenas o endereço físico de destino transportado no quadro. Assim, o endereço 
físico de destino determina a estação (interface) que efetivamente receberá o quadro. 


Exemplo 


Considere duas estações (A e B) conectadas ao mesmo segmento de rede física. Cada 
estação possui um endereço IP (I, e l)e um endereço físico (F, e F,). Agora, suponha que a 
estação A deseja enviar um datagrama IP para a estação B. Para tal, a estação A prepara o 
datagrama, incluindo os endereços IP de origem e destino (I, e |,). Observe que a estação A 
conhece o seu próprio endereço IP (I,), como também o endereço IP da estação B (I,), prova- 
velmente informado pela camada de aplicação ou diretamente pelo usuário. Em seguida, o 
datagrama é encapsulado em um quadro da rede física, que deve incluir os endereços físicos 
de origem e destino (F, e F,). No entanto, embora conheça o seu próprio endereço físico (F,), 
a estação A não conhece o endereço físico da estação B (F,). Logo, a estação A somente pode 
se comunicar com a estação B após descobrir o endereço físico dela. 


Q Lembre-se de que datagramas IP são encapsulados em quadros da rede física. 


Consequentemente, considerando que qualquer estação de origem sempre conhece o 
endereço IP da estação de destino, um mecanismo de resolução de endereços deve realizar 
o mapeamento do endereço IP de destino (geralmente sempre conhecido) para o endereço 
físico de destino (inicialmente desconhecido). 
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Técnicas de resolução de endereços 


Mapeamento direto: 
a Pressupõe que endereços físicos podem ser escolhidos pelo administrador. 
a O endereço físico deve possuir o mesmo valor do identificador de estação do endereço IP. 
Mapeamento dinâmico: 
ao Permite endereços físicos configurados pelo administrador ou fabricante. 
a Protocolo auxiliar realiza o mapeamento de forma transparente e sob demanda. 
m Rede física deve suportar broadcast. 
a Implementado na arquitetura TCP/IP pelo protocolo Address Resolution Protocol (ARP). 


Existem dois tipos de técnicas de resolução de endereços com o objetivo de realizar o 


mapeamento de endereços IP para seus respectivos endereços físicos. 
Mapeamento direto 


Geralmente adotado quando a tecnologia de rede permite ao administrador configurar 

os endereços IP e os endereços físicos das interfaces durante a instalação. Neste caso, 
tipicamente, o endereço físico de uma determinada interface deve possuir o mesmo valor 
do identificador de estação do endereço IP associado àquela interface. Por exemplo, se uma 
determinada interface possui o endereço IP 192.168.10.5, então o endereço físico da inter- 


face deve ser configurado com o valor 5. 
Mapeamento dinâmico 


Pode ser adotado tanto nas tecnologias de rede que permitem a configuração direta dos 
endereços físicos, quanto naquelas em que essa facilidade não é suportada. Assim, o mape- 
amento dinâmico torna os endereços IP independentes dos endereços físicos das interfaces. 
Ou seja, se uma determinada interface possui o endereço IP 192.168.10.5, então o endereço 
físico desta interface não precisa ser 5. No entanto, o mapeamento dinâmico somente pode 
ser adotado em redes físicas que suportam o conceito de broadcast. Para tal, o mapeamento 
dinâmico adota um protocolo auxiliar, que, enviando quadros em broadcast de camada de 


enlace, é capaz de realizar a resolução de endereços de forma transparente e sob demanda. 


als 


-Ọ- 







Para pensar 


Embora seja mais eficiente do que o mapeamento dinâmico, na prática o mapea- 
mento direto não é adotado, pois requer a configuração individual dos endereços 
físicos e gera uma dependência destes com os endereços IP. Na arquitetura TCP/IP, 

o protocolo Address Resolution Protocol (ARP) provê um eficiente mecanismo de reso- 


lução dinâmica de endereços. 


Protocolo ARP 


Objetivo de mapear endereços IP para seus respectivos endereços físicos. 


O protocolo ARP permite que qualquer estação encontre o endereço físico de outra estação 
na mesma rede física, com base apenas no endereço IP dessa outra estação. A resolução 
dinâmica suportada pelo protocolo ARP é bastante simples. A Figura 3.15 apresenta uma 
interação desse protocolo. 








Figura 3.15 
Funcionamento do 
protocolo ARP. 


F 


F- | 


A! ly B' B 


Quando a estação A deseja identificar o endereço físico da estação B (F,), na mesma rede 
física, a estação A envia, em broadcast, um pacote especial, denominado requisição ARP, 
para solicitar à estação com endereço IP (I,) que responda com o seu endereço físico 
correspondente. Nesse processo, a requisição ARP transporta os endereços IP (I,) e físico (F,) 


da estação requisitante (A), bem como o endereço IP (I,) a ser resolvido. 


Todas as estações, incluindo a estação B, recebem a requisição ARP. No entanto, apenas a 
estação B reconhece o endereço IP (l) a ser resolvido. Assim, somente a estação B envia a 
resposta ARP. Nesse processo, a resposta ARP transporta os endereços IP (|, e 1) € os ende- 
reços físicos (F, e F,) da estação requisitante (A) e da estação requisitada (B). Ao contrário 

da requisição ARP, que é enviada em broadcast, a resposta ARP é enviada diretamente para 
a estação requisitante (A), pois a estação requisitada (B) já conhece o endereço físico da 
estação requisitante. Após receber a resposta, a estação A pode enviar quadros diretamente 


para a estação B, usando o seu endereço físico (F,). 


Os datagramas IP e as mensagens ARP são diretamente encapsulados nos quadros da rede 
física. Assim, para viabilizar o processo de desencapsulamento, o cabeçalho dos quadros 
deve incluir um campo específico para identificar o protocolo encapsulado. Por exemplo, 


. em redes Ethernet, cada quadro possui um campo denominado Frame Type (tipo do quadro) 
Os interessados em 


detalhes do formato que, quando possui os valores 0x0800 e 0x0806, sinaliza o encapsulamento de datagramas 


das mensagens ARP IP e mensagens ARP, respectivamente. 
podem consultar o 
livro: COMER, Douglas 


E. Internetworking with Tabela ARP 


TCP/IP - Volume I: a 
Principles, Protocols A função da tabela ARP é armazenar os mapeamentos mais recentes e tornar o proto- 


and Architecture. 5th colo mais eficiente. Em relação a sua manutenção, requisições ARP podem atualizar as 
Edition. Prentice Hall, 


2005 tabelas de todas as estações da rede, enquanto respostas ARP atualizam a tabela da 


estação requisitante. 





Para reduzir o número de requisições e, assim, tornar mais eficiente o protocolo, cada 


Cache estação mantém uma cache que armazena os mapeamentos mais recentes. A cache é 


Mecanismo de arma- comumente denominada tabela ARP. Sempre que um mapeamento se torna necessário, a 
zenamento temporário 
de informações, cujas 
entradas são automa- jado é encontrado na tabela, nenhuma requisição ARP é enviada. 


tabela ARP é consultada antes de enviar qualquer requisição ARP. Se o mapeamento dese- 


ticamente removidas 
após um intervalo de ^A manutenção da tabela ARP de cada estação é realizada a partir das requisições e respostas 


tempo. ARP. Opcionalmente, todas as estações atualizam suas tabelas após receberem uma requi- 
sição ARP. Nessa atualização, o mapeamento associado à estação requisitante é incluído em 


suas tabelas. Por exemplo, na Figura 3.15, as estações C, D e B podem incluir em suas tabelas o 
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mapeamento |, F,, informado na requisição ARP. Em adição, sempre que a estação requisi- 
tante recebe a resposta ARP, o mapeamento informado é armazenado na sua tabela. Assim, 
na figura, a estação A inclui em sua tabela o mapeamento, Fẹ informado na resposta ARP. 


A listagem a seguir mostra um exemplo de tabela ARP no Windows. 


Q) Em sistemas Linux, a tabela ARP pode ser avaliada usando o comando arp. 


C:\>arp -a 

Interface: 200.130.26.6 --- 0x4 
Endereço IP Endereço físico Tipo 
200.130.26.228 00-06-29-30 3-35=-20 dinâmico 
ARES 0TZon25S OO=IS-C5-33=35- Sie dinâmico 
200.130.26.254 00-04-96-41-24-f0 dinâmico 


Podemos ver as seguintes informações da tabela ARP: 


o Endereço IP; 
a Endereço físico (MAC Address); 


o Tipo de mapeamento (estático ou dinâmico). 


Atabela ARP pode ser diretamente manipulada pelo administrador através das opções -s e 
-d do comando arp: 


oa Opção -d- permite a remoção de entradas desnecessárias associadas ao endereço 
IP informado; 


a Opção -s - permite a inclusão permanente de novas entradas na tabela. Na inclusão de 
uma nova entrada, deve-se informar o endereço IP e o respectivo endereço físico. Essa 
entrada será do tipo estático, por padrão. 


Protocolos para configuração automática de endereços IP 


Protocolos com o objetivo de atribuir endereços IP às estações de forma automática. 


Também são utilizados para carregar informações como máscara de rede e rota default. 
o RARP: é similar ao ARP e usa diretamente a camada de enlace. 


o BOOTP e DHCP: utilizam UDP sobre IP e o endereço de broadcast limitado. 


O protocolo ARP é utilizado para obter um endereço físico, partindo-se de um endereço IP. 
No entanto, a operação inversa, ou seja, a partir de um endereço físico se obter um ende- 


reço IP, também é comum para a configuração automática do endereço IP de uma estação. 


A configuração dos endereços IP das interfaces de uma estação pode ser feita de maneira 
estática - o endereço IP é conhecido previamente e foi designado pelo administrador da 
rede - ou de maneira dinâmica. Na configuração dinâmica, a estação pergunta a um ser- 
vidor qual é o endereço IP dela. Estações sem disco (diskless), por exemplo, precisam utilizar 
algum mecanismo para descobrir dinamicamente o seu endereço IP durante a inicialização, 
além de informações como o servidor de nomes (DNS), o servidor de arquivos e o arquivo 


de inicialização. A configuração automática de endereços IP pode ser realizada usando três 


Mais detalhes sobre o 


protocolo RARP podem 
ser obtidos no RFC 903. 





Figura 3.16 
Protocolo DHCP. 


protocolos: RARP, BOOTP e DHCP. Destes, estudaremos em mais detalhes o DHCP, por ser o 
protocolo mais adotado na prática. 


O protocolo RARP é uma adaptação do protocolo ARP. Ele adota o mesmo formato de men- 
sagens, que também são diretamente encapsuladas em quadros da rede física. O protocolo 
RARP se utiliza de broadcast para transmitir a solicitação por um endereço IP. Um servidor 
RARP que receba essa solicitação pode então transmitir a resposta diretamente para a 
estação solicitante. 


Protocolo DHCP 


Ea 
Utiliza UDP, IP e broadcast limitado, sendo capaz de transportar vários tipos de informa- 
ções, como máscara de rede, servidor de nomes e roteador default. 


Quatro mensagens: 
o DISCOVER. 

o OFFER. 

a REQUEST. 

o ACK. 





client server 


DISCOVERY 
broadcast 


OFFER 


unicast 


REQUEST 
broadcast 


awn 


unicast 


Ao contrario do protocolo RARP, que encapsula mensagens em quadros da camada de 
enlace, os protocolos BOOTstrap Protocol (BOOTP) e Dynamic Host Configuration Protocol 
(DHCP) utilizam os protocolos IP (camada de rede) e UDP (camada de transporte) para 
transportar suas mensagens. O funcionamento dos dois é semelhante, sendo que o DHCP é 
mais moderno e tornou-se o protocolo padrão para a configuração automática de endereços 
IP. De forma bastante resumida, a Figura 3.16 mostra o funcionamento do protocolo DHCP. 


oa Quando uma estação necessita solicitar um endereço IP, ela envia uma requisição DHCP 
chamada de DHCP DISCOVER. Essa solicitação utiliza como endereço de origem o IP 0.0.0.0 


e como endereço de destino o IP 255.255.255.255 - o endereço de broadcast limitado. 


a Um servidor DHCP que receba essa mensagem pode respondê-la com um DHCP OFFER, 
em que está contido o endereço IP a ser utilizado pela estação (como o servidor conhece 
o endereço físico da estação, ele pode mandar a resposta diretamente para a estação, 
sem se utilizar de broadcast). 


a Ao receber a resposta do servidor, a estação solicitante precisa confirmar que aceitou 
a oferta, utilizando para tal uma mensagem DHCP REQUEST. Essa mensagem ainda se 
utiliza dos endereços de origem 0.0.0.0 e de destino 255.255.255.255. 
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a Atransação é finalizada com a resposta do tipo DHCP ACK emitida pelo servidor, Y 








confirmando a designação do endereço. - protocolo BOOTP é 
definido pelo RFC 951. 
Detalhes sobre o 
protocolo DHCP podem 
ser obtidos no RFC 2131. 


Um ponto forte do protocolo DHCP é que ele pode carregar diversos tipos de informações 
(chamadas de “opções DHCP”), além de endereço IP e máscara de rede, como rota padrão a 


ser utilizada, servidor de nomes, servidor de arquivos etc. 


Mecanismos de entrega 


Entrega direta: 

ao Estações de origem e destino estão conectadas na mesma rede física. 
Entrega indireta: 

a Estações de origem e destino estão conectadas em redes físicas distintas. 
o Pode ser representada por uma sequência de entregas diretas. 

oa Datagramas são encaminhados através de roteadores intermediários. 


Estações conectadas à mesma rede física podem se comunicar diretamente. No entanto, 
estações conectadas a redes físicas diferentes devem enviar os datagramas IP por meio 

de roteadores intermediários (conceito de inter-rede). Dessa forma, a arquitetura TCP/IP 
suporta dois tipos de entrega de datagramas. 


Entrega direta 


Ocorre quando as estações de origem e destino estão conectadas na mesma rede física. 
Para exemplificar a entrega direta, considere duas estações (A e B) conectadas ao mesmo 
segmento de rede física. 


Suponha que a estação A deseja enviar um datagrama IP para a estação B. Nesse caso, 

o datagrama transporta os endereços IP das estações de origem (I,) e de destino (I,). Em 
seguida, a estação A, caso não tenha o mapeamento da estação B em sua cache, ativa o 
protocolo ARP para mapear o endereço IP da estação B (l,) para o seu respectivo endereço 
físico (F,). Após a resposta do protocolo ARP, o datagrama IP é encapsulado no quadro da 
rede física e, então, efetivamente transmitido. Esse quadro transporta os endereços físicos 
das estações de origem (F,) e destino (F,), conforme mostra a Figura 3.17. 





Entrega direta. 


Entrega indireta 


Ocorre quando as estações origem e destino estão conectadas a redes físicas distintas. Ela 


pode ser representada como uma sequência de entregas diretas. Inicialmente, a estação 





= 
> 


Figura 3.18 
Entrega indireta. 


FRN1 


origem entrega o datagrama a um roteador intermediário que, por sua vez, entrega a outro 
roteador intermediário e assim por diante, até que o último roteador do caminho entrega o 
datagrama à estação destino. 


Exemplo de entrega indireta: 


Considere duas estações (A e B), conectadas a redes físicas distintas (N1 e N2), por meio de 
um roteador (R) configurado como gateway padrão da estação A. Veja a Figura 3.18. Suponha 
que a estação A deseja enviar um datagrama IP para a estação B. Nesse caso, o datagrama 
sempre transporta os endereços IP das estações origem (l,) e destino (I,). A estação A deve 
encaminhar o datagrama para o roteador R (gateway padrão), cujo endereço IP na rede N1 é 
lyn ASSIM, após consultar a sua cache e verificar que não tem o mapeamento da interface 
do roteador R, a estação A ativa o protocolo ARP para mapear o endereço IP do roteador R 
na rede N1 (I,,,,) para o seu respectivo endereço físico (Fpp). Em seguida, o datagrama IP é 
encapsulado no quadro da rede física N1 e efetivamente transmitido. O quadro transporta 


os endereços físicos da estação origem (F,) e do roteador R na rede N1 (F,,,,,). Após receber o 


pina) 
datagrama, o roteador pode entregar o datagrama à estação destino. Assim, R ativa o proto- 
colo ARP para mapear o endereço IP da estação destino (I,) para o seu respectivo endereço 

físico (F,). Por fim, o datagrama IP é encapsulado no quadro da rede física N2 e efetivamente 
transmitido. Nesse caso, o quadro transporta os endereços físicos do roteador R na rede N2 
(F 


rn2) € da estação destino (F,). 


Da mesma forma, caso cheguem datagramas IP para outra rede destino, eles serão encami- 
nhados ao gateway padrão, que através do processo descrito acima, faz a entrega ao destino 
final ou a outro roteador intermediário. Isto significa que o gateway padrão pode também 
enviar mensagens ARP em broadcast. 


Fa FRN1 pe a FRN2 Fg 


(ae o) Datagrama Datagrama 
L Jouaorodaredeni (Frae J Quatro da rede n2 


Um conjunto de máquinas numa rede local - tal que todas recebam quadros em broadcast 





de suas vizinhas - é chamado de domínio de broadcast. 


Duas coisas importantes sobre quadros em broadcast: 


1. Os hubs e switches propagam os quadros em broadcast por padrão; 
2. Os roteadores NÃO propagam os quadros em broadcast por padrão. 


Assim, se os quadros em broadcast estiverem congestionando o tráfego da rede local, a solução 
é dividir a rede local em sub-redes IP usando roteadores ou dividir a rede local em VLANs 
(Virtual LANs) usando switches. Note que a segmentação das redes locais usando switches (sem 
VLANS) resolve o problema de domínio de colisão, mas não o de domínio de broadcast. 
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Desperdício de endereços 


Caso o endereço de rede classe C 192.168.10.0 seja atribuído a uma rede com 100 estações, 
apenas 100 dos 254 endereços permitidos são efetivamente utilizados. Consequentemente, 
154 endereços são desperdiçados. Pior ainda, caso surja outra rede física com menos de 
154 estações, esses endereços que estão sobrando não podem ser atribuídos, pois qual- 
quer endereço de rede somente pode ser atribuído a uma única rede física. Assim, outro 
endereço de rede deve ser atribuído para essa nova rede física, aumentando provavelmente 


ainda mais o desperdício de endereços. 


Se o número de estações da rede original aumentar de 100 para 300, apenas um endereço 
de rede classe B pode ser usado. Supondo que o endereço de rede classe B 172.16.0.0 tenha 
sido atribuído para essa rede, o desperdício é muito maior, pois um endereço classe B possui 
65.534 (2'6-2) endereços permitidos; são, exatamente, 65.234 endereços desperdiçados. 


Assim, considerando o rápido crescimento da internet, o elevado desperdício de endereços 
tornou evidente que o esquema original de endereçamento IPv4 era bastante insatisfatório. 
Esse problema foi considerado muito crítico pelos grupos responsáveis pela padronização 
da arquitetura TCP/IP, pois as previsões denunciavam um rápido esgotamento do espaço 

de endereçamento IPv4, impossibilitando a conexão de novas redes e inviabilizando a 


expansão da internet. 


Consequentemente, soluções deveriam ser propostas com os objetivos de minimizar o des- 
perdício de endereços e maximizar o tempo de vida do esquema de endereçamento baseado 
em endereços de apenas 32 bits. Veremos essas soluções a seguir e no próximo capítulo. 


Ea 
O esquema de endereçamento IPv4 original é inviável tecnicamente, pois cada rede física 
deve ter um prefixo de rede único. A analogia seria de duas ruas com nomes distintos. 


Imagine uma rede física classe A: 
o Escalabilidade de hardware (24 milhões de portas de switch). 
o Escalabilidade de software (excesso de tráfego). 


O mesmo vale para uma rede classe B (65 mil portas). Já uma rede classe C pode se 


tornar pequena. 


Quando descrevemos as classes de endereços IPv4 identificamos que o esquema original de 
endereçamento IPv4 é bastante insatisfatório, pois gera um elevado desperdício de ende- 


reços que pode ocasionar o rápido esgotamento dos endereços IPv4. 


Consequentemente, soluções alternativas deveriam ser propostas com o objetivo de mini- 

mizar o desperdício de endereços e, assim, maximizar o tempo de vida do espaço de ende- 

reçamento de 32 bits. Na tentativa de solucionar o desperdício de endereços, identificou-se 

que o principal problema era a associação de um prefixo de rede a uma única rede física. Prefixo de rede 
RE ear ent eo ane eee Ee ' 


a Rápido esgotamento do espaço de endereçamento IPv4. x que identifica a rede de 
forma única e individual. 





a Impossibilidade de conexão de novas redes. 

a Crescimento da internet é inviabilizado. 

a Solução: compartilhar um único endereço de rede entre múltiplas redes físicas. 
Objetivo: 

a Minimizar o desperdício de endereços. 


a Maximizar o tempo de vida do espaço de endereçamento de 32 bits. 


Endereco de sub-rede 


Representado pelo 
prefixo de sub-rede 

e identificador de 
estação, possuindo 
neste último campo 
todos os bits iguais a 0. 


Em consequência do desperdício de endereços, fica impossibilitada a conexão de novas 
redes e, portanto, o crescimento da internet é inviabilizado. Para solucionar esse pro- 
blema, o esquema de endereçamento de sub-redes foi padronizado na arquitetura TCP/ 

IP, permitindo o compartilhamento de um único endereço de rede, classe A, B ou C, entre 
diversas redes físicas. Pretendia-se com este esquema conseguir minimizar o desperdício 
de endereços e assim maximizar o tempo de vida do espaço de endereçamento de 32 bits, 
enquanto uma solução definitiva não era encontrada. Veremos adiante que, apesar de todos 
os esforços, está sendo muito difícil manter o endereçamento IPv4. Veremos também que a 
solução definitiva é o endereçamento IPv6. 


No entanto, o conceito de sub-redes não se mostrou plenamente eficaz, pois a atribuição de ende- 
reços classe B ainda representava um enorme desperdício de endereços. Na prática, para cada 


endereço classe B, geralmente, apenas uma pequena parcela dos endereços de sub-rede é efeti- 


vamente atribuída, representando, assim, um grande desperdício do espaço de endereçamento. 


Avaliando o uso ineficiente de endereços classe B, identificou-se que a principal razão era a 
inexistência de um tamanho de rede adequado às necessidades das instituições. Enquanto 
endereços classe C são bastante pequenos, endereços classe B são demasiadamente 
grandes. Nesse contexto, o esquema de endereçamento de super-redes foi padronizado 
na arquitetura TCP/IP com o objetivo de permitir a atribuição de blocos de endereços com 


tamanhos adequados às necessidades das instituições. 


Sub-redes 


a Permitem compartilhar um único endereço de rede entre diversas redes físicas. 
a Minimizam o desperdício de endereços. 
a Exemplo: rede classe B 172.16.0.0 pode ser dividida em 256 sub-redes classe C. 


ao Endereços de sub-rede podem ter um número variado de bits no prefixo de rede e 
identificador de estação. 


m O novo prefixo de rede deve ser maior que o prefixo original. 


m O prefixo de rede e o identificador de estação devem possuir 32 bits. 





o Endereços de rede classe A, B ou C podem ser usados para criar sub-redes. 


Uma forma bastante simples de entender o conceito de sub-redes é imaginar uma insti- 
tuição que possui um único endereço de rede classe B, e deseja utilizar esse mesmo ende- 
reço de rede em diferentes redes físicas. Usando o endereçamento de sub-redes, o objetivo 
é dividir o endereço classe B - que possui 16 bits no prefixo de rede e 16 bits no identificador 
de estação -em diversos endereços de sub-rede com uma estrutura hierárquica similar a 
endereços de rede classe C, ou seja, 24 bits no prefixo de rede e 8 bits no identificador de 


estação. Dessa forma, cada endereço de sub-rede pode ser atribuído a uma única rede física. 


Esse esquema é ilustrado na Figura 3.19, em que o endereço de rede classe B 172.16.0.0 
é dividido em diversos endereços de sub-rede, que possuem uma estrutura similar a 

um endereço de rede classe C (172.16.0.0, 172.16.1.0, ..., 172.16.254.0 e 172.16.255.0). Em 
seguida, a instituição atribui os endereços de sub-rede 172.16.1.0, 172.16.2.0, 172.16.3.0 
e 172.16.4.0 para as redes N1, N2, N3 e N4, respectivamente. Observe que todas as redes 


físicas compartilham o prefixo de rede classe B 172.16.0.0. 
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172.16.3.0 


R1 + 
172.16.1.0 + 172.16.2.0 
Figura 3.19 
Exemplo de 
172.16.4.0 dibfedes. 


Embora o exemplo apresente endereços de sub-rede com 24 bits no prefixo de rede e 8 bits 
no identificador de estação, o esquema de sub-redes permite a criação de endereços de 
sub-rede com número variado de bits no prefixo de rede e identificador de estação, desde 
que o prefixo de rede dos endereços de sub-rede seja maior que aquele associado ao res- 
pectivo endereço de rede. Isso significa que não é possível, com a rede utilizada no exemplo 
anterior, tentar associar um endereço de sub-rede com 12 bits no prefixo de rede. Além 
disso, o total de bits do prefixo de rede e identificador de estação deve ser igual a 32. Por 
exemplo, a partir de um endereço de rede classe B, é possível criar endereços de sub-rede 


com 22 bits no prefixo de rede e 10 bits no identificador de estação. 


Apesar do exemplo adotar um endereço de rede classe B, o esquema de sub-redes pode ser 
aplicado a endereços de rede classe A, B ou C. Por exemplo, é possível dividir um endereço 
de rede classe C em diversos endereços de sub-rede, cada um deles com 27 bits no prefixo 


de rede e 5 bits no identificador de estação. 


Por enquanto, é suficiente entender que o endereçamento de sub-redes pode minimizar o 
desperdício de endereços, pois permite o compartilhamento de um único endereço de rede 
entre diversas redes físicas. 


Arquiteturas de endereçamento 


Arquitetura classful: 
a Adota o conceito de classes A, B e C. 
m Roteamento usa o conceito de classes. 
m Suporta o esquema de sub-redes. 
m Não suporta o esquema de super-redes (agrupamento de redes). 
Arquitetura classless: 
o Não adota o conceito de classes A, B e C. 
m Roteamento não usa o conceito de classes. 
m Suporta os esquemas de sub-redes e super-redes. 
Os esquemas de endereçamento de sub-redes e super-redes proveem facilidades com- 


plementares e definem diferentes arquiteturas de endereçamento que são denominadas 


arquitetura classful e arquitetura classless. 


ao Aarquitetura de endereçamento classful, como o próprio nome sugere, utiliza o conceito 
de classes de endereços A, Be C. Implementações do protocolo IPv4 que suportam a 
arquitetura classful permitem a adoção do esquema de endereçamento de sub-redes, 
porém não permitem o esquema de endereçamento de super-redes. Essa limitação é 
resultado da implementação da função de roteamento que utiliza o conceito de classes 
de endereços para selecionar as rotas. 


ao Aarquitetura de endereçamento classless, como o próprio nome indica, não utiliza o 
conceito de classes de endereços. Os endereços de rede são vistos apenas como blocos 
contiguos de endereços IPv4. Implementações do protocolo IPv4 que suportam a arqui- 
tetura classless permitem a adoção do endereçamento de super-redes, como também do 
endereçamento de sub-redes. Essa flexibilidade é resultado da implementação da função 


de roteamento que não utiliza o conceito de classes de endereços para selecionar as rotas. 


Vale ressaltar que, originalmente, o termo sub-rede era referenciado apenas como a sub- 
divisão de um endereço de rede classe A, B ou C em endereços de sub-rede. No entanto, 
após a padronização do esquema de endereçamento classless, o termo sub-rede passa a se 
referir também à subdivisão de um bloco de endereços em blocos menores. Por exemplo, 
é possível dividir um bloco de 512 endereços em 8 blocos de 64 endereços. Cada um destes 


blocos de 64 endereços constitui uma sub-rede do bloco de 512 endereços. 


Diferenças entre arquiteturas 


Arquitetura classful: a 


a Sub-rede é a subdivisão de um endereço de rede classe A, B ou C em endereços de sub-rede. 
a Proíbe alguns endereços de sub-rede. 
m Não permite recursividade de sub-redes. 

Arquitetura classless: 

a Sub-rede é a subdivisão de um bloco de endereços em blocos menores. 


m Permite todos os endereços de sub-rede. 





m Permite recursividade de sub-redes. 


A arquitetura classless é uma extensão da arquitetura classful, ou seja, a arquitetura classless 
provê as mesmas facilidades da arquitetura classful, porém acrescenta novas facilidades. 
Embora as duas arquiteturas suportem o esquema de endereçamento de sub-redes, a 
arquitetura classless é ainda mais poderosa que a arquitetura classful, pois permite um 
melhor aproveitamento dos endereços. Em outras palavras, a arquitetura classful proíbe 

o uso de alguns endereços de sub-rede, enquanto a arquitetura classless permite o uso de 
todos os endereços de sub-rede. 


Outra limitação é que a arquitetura classful não permite a aplicação recursiva do conceito de 
sub-redes. Em outras palavras, uma vez que um endereço de rede classe A, B ou C é dividido 
em um conjunto de endereços de sub-redes, estes últimos não podem sofrer outro processo 
de divisão. Por outro lado, na arquitetura classless, quando um bloco de endereços é dividido 


em blocos menores, estes últimos podem ser novamente divididos, e assim por diante. 


Endereçamento de sub-redes 


am 
O endereçamento de sub-redes permite que um único endereço de rede classe A, B ou C 
seja compartilhado entre diversas redes físicas. Ele modifica a estrutura hierárquica dos | 


endereços IP e divide o identificador de estação para representar as sub-redes. 
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O esquema de endereçamento de sub-redes permite que um único endereço de rede, classe 
A, B ou C, seja compartilhado entre diversas redes físicas, também denominadas, neste con- 
texto, sub-redes físicas. Para tal, o endereço de rede é dividido em diversos endereços de 
sub-rede, modificando a estrutura hierárquica definida pelo identificador de rede (prefixo 
de rede) e pelo identificador de estação. A Figura 3.20 mostra a modificação requerida para 


representar as sub-redes. 
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Identificador de rede Identificador de estação 
Figura 3.20 
Identificador de rede Identificador de sub-rede Identificador de estação Endereçamento de 


sub-redes. 


| | 


Ao invés de considerar que um endereço IP é composto pelo identificador de rede e pelo 


identificador de estação, a porção do identificador de estação é dividida em duas partes: 


o Identificador de sub-rede - identifica, juntamente com o identificador de rede, a 


rede física de forma única e individual. 


o Identificador de estação - identifica a estação (interface) dentro da respectiva rede 
física de forma única de individual. 


A concatenação dos identificadores de rede e sub-rede é comumente denominada de 
prefixo de sub-rede. Este esquema de endereçamento de sub-redes está descrito nos RFCs 
917 e 950 (padrão). O objetivo é diminuir o “salto” na quantidade de estações quando se 
cresce de um endereço de rede para outro em uma determinada classe de endereço A, Bou 
C, inserindo degraus intermediários que são as sub-redes. Note que os bits usados para a 


criação e identificação das sub-redes são extraídos dos bits do identificador de estação. 


Os bits do prefixo de rede original não podem ser usados para sub-redes, senão 

Q estaríamos modificando o prefixo de rede original, o que não é permitido, uma vez 
que os prefixos de rede originais são atribuídos por uma autoridade de atribuição de 
números da internet (IANA). 


Hierarquia de endereçamento 


Por exemplo, na Figura 3.19, o endereço de rede classe B 172.16.0.0, que possui 16 bits no 
prefixo de rede e 16 bits no identificador de estação, foi dividido nos endereços de sub-rede 
172.16.1.0, 172.16.2.0, 172.16.3.0 e 172.16.4.0, que possuem 16 bits no prefixo de rede, 8 bits 
no identificador de sub-rede e 8 bits no identificador de estação. Nesse exemplo, os prefixos 
de sub- rede são 172.16.1, 172.16.2, 172.16.3 e 172.16.4. Veremos posteriormente, em deta- 


Ihes, como estes endereços de sub-rede são criados e representados. 


Regras de atribuição de endereços 


No esquema de endereçamento de sub-redes, a atribuição de endereços às interfaces de 
estações e roteadores segue regras semelhantes àquelas do esquema endereçamento IP 
original, porém aplicadas aos endereços de sub-rede. 


Figura 3.21 
Exemplo de 
atribuição de 
endereços. 


Figura 3.22 
Endereços de 
sub-rede. 


Figura 3.23 
Endereços de 
broadcast direto. 


o Diferentes prefixos de sub-rede devem ser adotados para diferentes redes físicas. 


a Um único prefixo de sub-rede deve ser compartilhado pelas interfaces conectadas a 
uma mesma rede física. 


a Um único identificador de estação deve ser atribuído a cada interface conectada a 
uma determinada rede física. 








172.16.1.1 RI 172.16.2.1 
172.16.1.0 he 172.16.2.0 
172.16.1.3 “+ 172.16.2.3 
172.16.1.2 172.16.2.2 


A Figura 3.21 apresenta um exemplo de atribuição de endereços. Observe que todas as 
interfaces conectadas às redes N1 e N2 compartilham o prefixo de sub-rede, identificando 
as respectivas redes físicas. Ou seja, as estações (E1 e E2) e a interface do roteador (R1) 
compartilham o prefixo 172.16.1 da sub-rede N1, enquanto as estações (E3 e E4) e a outra 
interface do roteador (R1) compartilham o prefixo 172.16.2 da sub-rede N2. 


Por outro lado, na sub-rede N1, as estações (E1 e E2) e o roteador (R1) possuem os identi- 
ficadores de estação 1, 2 e 3, respectivamente. Já na sub-rede N2, as estações (E3 e E4) e o 
roteador (R1) possuem os identificadores de estação 1,2 e 3, respectivamente. Observe que 
interfaces conectadas a diferentes redes físicas podem possuir os mesmos identificadores de 


estação, pois seus prefixos de sub-rede são diferentes e asseguram a unicidade de endereços. 






Analogia: casas situadas em ruas diferentes podem ter o mesmo número. v 


Endereços de sub-rede e broadcast direto 


Endereços de sub-rede podem ser utilizados para referenciar a rede física. 


0 31 
Identificador de rede Identificador de sub-rede [ae 


Endereços de broadcast direto permitem o envio de datagramas para todas as estações 
da sub-rede. 
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Identificador de rede Identificador de sub-rede 


Assim como endereços de rede podem ser usados para referenciar as redes físicas no 
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esquema de endereçamento IP original, de forma análoga, no esquema de endereçamento de 
sub-redes, endereços de sub-rede podem ser usados para referenciar as novas redes físicas. 
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No esquema de endereçamento IP original, o endereço de rede é representado pelo prefixo 
de rede e pelo identificador de estação, este último campo possuindo todos os bits iguais 

a O. De forma semelhante, no esquema de endereçamento de sub-redes, o endereço de 
sub-rede é representado pelo prefixo de sub-rede e pelo identificador de estação, com este 
último campo possuindo todos os bits iguais a 0. Assim, o identificador de estação, cujos bits 


são iguais a 0, é reservado e nunca atribuído a nenhuma interface de uma rede física. 


A Figura 3.22 ilustra a convenção para endereços de sub-rede. Por exemplo, na Figura 3.21, 
como o identificador de estação possui apenas 8 bits, os endereços das sub-redes N1 e 

N2 são 172.16.1.0 e 172.16.2.0, respectivamente. Uma vez que cada rede física possui um 
endereço de sub-rede particular, o conceito de broadcast direto também pode ser adotado, 
permitindo o envio de datagramas IP para todas as estações (interfaces de estações e rotea- 
dores) de uma determinada sub-rede a partir de qualquer estação da inter-rede TCP/IP. 


No esquema de endereçamento IP original, o endereço de broadcast direto é representado 
pelo prefixo de rede e pelo identificador de estação, possuindo este último campo todos 

os bits iguais a 1. De forma semelhante, no esquema de endereçamento de sub-redes, o 
endereço de broadcast direto da sub-rede é representado pelo prefixo de sub-rede e pelo 
identificador de estação, este último campo possuindo todos os bits iguais a 1. Assim, o 
identificador de estação, cujos bits são iguais a 1, é reservado e nunca atribuído a nenhuma 
interface da rede física. 


A Figura 3.23 ilustra a convenção para endereços de broadcast direto de sub-redes. Por 
exemplo, na Figura 3.21, como o identificador de estação possui apenas 8 bits, os endereços 
de broadcast direto das sub-redes N1 e N2 são 172.16.1.255 e 172.16.2.255, respectivamente. 


Máscara de sub-rede 

am 
A máscara de sub-rede tem o objetivo de delimitar a posição do prefixo de sub-rede e do 
identificador de estação. É representada por padrão de 32 bits. 
a Possui bits 1 no prefixo de sub-rede. 
a Possui bits O no identificador de estação. 
Para delimitar os bits que compõem o prefixo de sub-rede e o identificador de estação, o 
esquema de endereçamento de sub-redes define o conceito de máscara de sub-rede, que 


representa uma simples adaptação do conceito de máscara de rede do endereçamento IP 


original. A Figura 3.24 ilustra a estrutura de uma máscara de rede. 


Co M o 
Figura 3.24 
Decimal 172.16.1.1 255.255.255.0 Mascara de 


sub-rede. 
Contagem de Bits 172.16.1.1/24 
Comparação: 


ao Máscara de rede - padrão de 32 bits que contém bits 1 na posição do prefixo de rede e 


bits O na posição do identificador de estação. 


Figura 3.25 a/b 
Quantidade 

de endereços 
de sub-redes. 


o Máscara de sub-rede - padrão de 32 bits que contém bits 1 na posição do prefixo de 
sub-rede (identificador de rede + identificador de sub-rede) e bits O na posição do identi- 


ficador de estação. 


Da mesma forma que as máscaras de rede, as máscaras de sub-rede podem ser escritas 
usando a notação decimal (dotted-decimal notation) ou a contagem de bits (bit count). 

A Figura 3.24 mostra um exemplo de endereço IP e respectiva máscara de sub-rede nas 
notações decimal e contagem de bits. Nesse caso, o prefixo da sub-rede é 172.16.1, pois a 
máscara possui 24 bits. Logo, o endereço de sub-rede e o endereço de broadcast direto da 
sub-rede são 172.16.1.0 e 172.16.1.255, respectivamente. O endereço 172.16.1.1 refere-se a 
uma estação desta sub-rede. 


É importante ressaltar que a máscara default de uma determinada classe de rede possui a 
mesma quantidade de bits 1 do tamanho do prefixo de rede daquela classe. Assim, as máscaras 
default de redes classes A, B e C possuem 8 (255.0.0.0), 16 (255.255.0.0) e 24 (255.255.255.0) bits 1, 
pois os identificadores de rede dessas classes possuem 8, 16 e 24 bits, respectivamente. 


Embora o termo máscara de rede também seja usado com o mesmo significado de máscara 
de sub-rede, o contexto torna óbvio o tipo de máscara tratada. Como regra geral, temos que, 
se a máscara é diferente da máscara default da classe do endereço em questão, trata-se então 
de máscara de sub-rede. 


A regra “all bits O or 1” se aplica ao identificador de estação em qualquer arquitetura 
Q) (classful ou classless). Na arquitetura de endereçamento classful não são permitidos os 


endereços de sub-rede com todos os bits do identificador de sub-rede iguais a 0 ou 1. 


com todos os bits do identificador de sub-rede iguais a 0 (zero) ou 1. | 


Na arquitetura de endereçamento classless são permitidos os endereços de sub-rede 


Nós vimos que o identificador de estação não pode ter todos os bits O (reservado para 

o endereço da sub-rede) e não pode ter todos os bits 1 (reservado para o endereço de 
broadcast da sub-rede). Esta regra é chamada de “all bits O or 1” (todos os bits 0 ou 1) e se 
aplica ao identificador de estação em qualquer arquitetura (classful ou classless); porém, só 
se aplica ao prefixo de sub-rede na arquitetura classful. Esta é uma limitação importante da 
arquitetura classful, como veremos adiante nos exemplos de cálculo de sub-rede. Portanto, 
é importante ressaltar que o identificador de sub-rede é calculado de forma diferente 


dependendo da arquitetura, classful ou classless. 


Protocolo DHCP 


O número de sub-redes é definido pelo número de bits do identificador de sub-rede. 


Identificador n Endereços 
de sub-rede e 2 de sub-redes 


am 
Na arquitetura classful não são permitidos endereços de sub-rede cujos bits do identifi- 
cador de sub-rede sejam todos iguais a 0 ou 1. | 


Identificador Qn 2 Endereços 
de sub-rede e be de sub-redes 
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Já conhecemos os principais conceitos e algumas regras associadas ao esquema de ende- 
reçamento de sub-redes. No entanto, algumas regras adicionais devem ser atendidas para 
criar e atribuir endereços às sub-redes. No projeto de sub-redes, primeiramente, deve-se 
decidir o número de bits que serão usados no identificador de sub-rede, pois a quantidade 
de endereços de sub-rede que podem ser criados depende do número de bits deste identi- 
ficador. A princípio, se o identificador de sub-rede possui “n” bits, então podem ser criados 


“2™ endereços de sub-redes. 


Por exemplo, considere que estamos criando sub-redes do endereço classe C 192.168.1.0, 
com 3 bits no identificador de sub-rede. Nesse caso, podemos criar 8 (2º) endereços de 
sub-redes, ilustrados na Figura 3.26. Observe que os endereços de sub-rede são todos 
aqueles gerados pela combinação de valores possíveis no identificador de sub-rede. A 
máscara possui 27 bits, sendo 24 bits do identificador de rede do endereço classe Ce 3 bits 


do identificador de sub-rede. 


0 23 27 31 


11000000 10101000 00000001 (000) 00000 | 192.168.1.0/27 

11000000 10101000 00000001 001 | 00000 | 192.168.1.32/27 
11000000 10101000 00000001 010 | 00000 | 192.168.1.64/27 
11000000 10101000 00000001 011 | 00000 | 192.168.1.96/27 


11000000 10101000 00000001 100 | 00000 | 192.168.1.128/27 


11000000 10101000 00000001 101 | 00000 | 192.168.1.160/27 




















11000000 10101000 00000001 110 | 00000 | 192.168.1.192/27 
Figura 3.26 
Exemplo de 
11000000 10101000 00000001 111 | 00000 | 192.168.1.224/27 sub-redes. 


No entanto, na arquitetura classful não são permitidos os endereços de sub-rede com todos 
os bits do identificador de sub-rede iguais a O ou 1. Logo, no exemplo da Figura 3.26, os 
endereços de sub-rede 192.168.1.0/27 e 192.168.1.224/27 não podem ser usados. Essa 
restrição evita que os roteadores confundam o endereço da rede (192.168.1.0) com o 
endereço da primeira sub-rede (192.168.1.0/27), e o endereço de broadcast na rede 
(192.168.1.255) com o endereço de broadcast da última sub-rede (192.168.1.255/27). 
Consequentemente, na prática, se o identificador de sub-rede possui “n” bits, então 


somente “2" - 2" endereços de sub-redes podem ser criados. 


Em função dessa restrição da arquitetura classful, não pode existir um identificador de 
sub-rede com apenas 1 bit, pois a primeira e a última sub-rede devem sempre ser eliminadas. 
Assim, endereços de rede classes A, Be C não podem usar sub-redes com máscaras de 9, 
17 e 25 bits, respectivamente. 


am 
Espaço de endereçamento de estação é o conjunto de endereços que compartilham um 


mesmo prefixo de sub-rede. J 


Figura 3.27 a/b 
Quantidade de 
endereços 

de estações. 


Figura 3.28 
Espaço de endere- 
çamento e ende- 
reços permitidos. 


Identificador n 
de estação [fn | = Endereços 


a 
Endereços permitidos de estação é o conjunto de endereços que podem ser atribuídos 
às interfaces. | 


Identificador n 


Considerando um determinado endereço de sub-rede, o espaço de endereçamento é 
constituído por todos os endereços que podem ser expressos por meio da variação do 
identificador de estação e os endereços permitidos são todos aqueles que podem ser 
atribuídos às interfaces de estações e roteadores. Portanto, os endereços permitidos são 
todos os endereços do espaço de endereçamento, exceto o primeiro (endereço de sub-rede) 
e o último (endereço de broadcast direto da sub-rede). Logo, se uma determinada sub-rede 


possui “n” bits no identificador de estação, então esta sub-rede possui um espaço de 
endereçamento com “2"" endereços e “2" - 2" endereços permitidos. 


Tomando como base o identificador de estação das sub-redes da Figura 3.26, que possui 

5 bits, podemos afirmar que cada uma destas sub-redes possui 32 (2º) endereços no espaço 
de endereçamento e 30 (2º - 2) endereços permitidos, ilustrados na tabela a seguir. Observe 
que os endereços de estação são todos aqueles gerados pela combinação de valores permi- 
tidos no identificador de estação. 


Endereço de sub-rede Espaço de endereçamento Endereços permitidos 


192.168.1.32/27 192.168.1.32 - 192.168.1.33 - 
192.168.1.63 192.168.1.62 
192.168.1.64/27 192.168.1.64 - 192.168,1.65 - 
192.168.1.95 192.168,1.94 
192.168.1.96/27 192.168.1.96 - 192.168.1.97 - 
192.168.1.127 192.168.1.126 
192.168.1.128/27 192.168.1.128 - 192.168.1.129 - 
192.168.1.159 192.168.1.158 
192.168.1.160/27 192.168.1.160 - 192.168.1.161 - 
192.168.1.191 192.168.1.190 
192.168.1.192/27 192.168.1.192 - 192.168.1.193 - 
192.168.1.223 192.168.1.222 


Considerando os endereços permitidos de uma sub-rede, não pode existir um identificador 
de estação com menos de 2 bits, pois o primeiro e o último endereços são reservados para o 
endereço de sub-rede e broadcast direto. Logo, o identificador de estação deve possuir pelo 
menos 2 bits. Consequentemente, endereços de rede classes A, Be C não podem usar 
sub-redes com máscaras maiores que 30 bits. 


Cálculo de máscara de sub-redes 


Antes de apresentar o processo de cálculo de sub-redes propriamente dito, vamos ilustrar o 


conceito de sub-rede de uma maneira visual bastante didática: método BOX. 
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Este método é a maneira mais simples de visualizar a divisão de uma rede em sub-redes e os 
respectivos endereços de sub-rede, broadcast direto e endereços permitidos. Este método é 
aplicável a um octeto de cada vez, seja para redes classe A, B ou C. Vamos exemplificar com 
uma rede classe C: 200.130.26.0/24. 


A rede pode ser representada por um quadrado (BOX) que representa os 256 endereços do 
espaço de endereçamento, conforme mostrado na Figura 3.29. 


Método BOX 


a Uma sub-rede - 256 endereços. 

a Máscara: 255.255.255.0 ou /24. 

a Endereço de sub-rede: 200.130.26.0/24. 

ao Endereço de broadcast direto: 200.130.26.255/24. 

Esse método permite visualizar facilmente as divisões em sub-redes, inclusive com máscara 
de tamanho variável (VLSM). Ele se baseia na divisão de um octeto inteiro, não se aplicando 
quando se trata de divisão de blocos de endereços que extrapolam os limites de um octeto. 
Assim, ele pode ser aplicado ao segundo octeto (na divisão em sub-redes de uma rede 


classe A), terceiro octeto (na divisão em sub-redes de uma rede classe B) e no quarto octeto 


(na divisão em sub-redes de uma rede classe C). 


A Figura 3.29 representa 1 octeto inteiro, sem divisão em sub-redes, portanto, teremos o 
espaço de endereçamento de 256 endereços, sendo o primeiro (200.130.26.0) o endereço de 
rede e o último (200.130.26.255) o endereço de broadcast direto. Ambos estão escritos dentro 


do quadrado (BOX), no canto superior esquerdo e no canto inferior direito, respectivamente. 


Figura 3.29 
255 Uma sub-rede. 


o Duas sub-redes - 128 endereços em cada uma. 
a Máscara: 255.255.255.128 ou /25. 
a Endereços de sub-rede: 200.130.26.0/25 e 200.130.26.128/25. 


a Endereços de broadcast direto: 200.130.26.127/25 e 200.130.26.255/25. 


Figura 3.30 
Duas sub-redes. 


Figura 3.31 
Quatro sub-redes. 


127 255 


Dividindo o quadrado em duas partes, obtemos duas sub-redes com 128 endereços cada 
(Figura 3.30). Observe que os endereços de sub-rede e broadcast direto das duas sub-redes 
estão escritos dentro dos respectivos retângulos. 

o 4sub-redes - 64 endereços em cada uma. 
a Mascara: 255.255.255.192 ou /26. 

o Endereços de sub-rede: 200.130.26.0/26 até 20 0.130.26.192/26. 


ao Endereços de broadcast direto: 200.130.26.63/26 até 200.130.26.255/26. 





Dividindo o quadrado novamente, obtemos 4 sub-redes com 64 endereços cada (Figura 3.31). 


Observe que, em cada quadrado, os números representam o endereço de rede e o endereço 
de broadcast direto, respectivamente. O intervalo entre eles representa os endereços que 
podem ser atribuídos às interfaces de rede dos equipamentos. 

a 8 sub-redes - 32 endereços em cada uma. 

a Mascara: 255.255.255.224 ou /27. 

o Endereços de sub-rede: 200.130.26.0/27 até 200.130.26.224/27. 


ao Endereços de broadcast direto: 200.130.26.31/27 até 200.130.26.255/27. 
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Figura 3.32 
Oito sub-redes. 


Dividindo o quadrado novamente, obtemos 8 sub-redes com 32 endereços cada (Figura 3.32). 


Observe que o número de sub-redes multiplicado pelo número de endereços em cada sub-rede 


é sempre igual a 256, que é o espaço de endereçamento de 1 octeto. 





16 sub-redes - 16 endereços em cada uma. 

Máscara: 255.255.255.240 ou /28. 

Endereços de sub-rede: 200.130.26.0/28 até 200.130.26.240/28. 
Endereços de broadcast direto: 200.130.26.15/28 até 200.130.26.255/28. 


Figura 3.33 
Dezesseis sub-redes. 


Dividindo o quadrado novamente, obtemos 16 sub-redes com 16 endereços cada (Figura 3.33). 


E assim por diante, até a máscara /30, que é a maior máscara que pode ser usada, conforme 


explicado. Vamos agora explicar o processo de cálculo de sub-redes de duas maneiras: a 


tradicional (em binário) e a simplificada (em decimal). 


Método binário 


Dada uma rede classe C 200.130.26.0/24. 
Deseja-se 30 endereços por sub-rede. 

5 bits de hosts: 2º = 32 endereços/sub-rede. 

3 bits de sub-rede: 8 -5=3. 

A máscara (ver tabela) é: 255.255.255.224 ou /27. 
ID sub-redes: 0, 32, 64, 96, ..., 224. 


O método binário baseia-se na tabela de máscaras de sub-rede em binário, conforme mostrado 
na Figura 3.34. 








Bits bit8 bit 7 bit6 bit5 bit4 bit3 bit2 bit 1 Decimal #Sub- #hosts IDsub-redes 
E E z z z 7 0 7 -rede / sub- 
Pesos 2 A g O B a a da -rede 
Máscara É 5 : ; : z E E : É É 
00000000 “o So Fo Colo Fo o 0 É i256 io 
1000000: 1 o o oo oo Cos i128 i 0,128 
MooooooM: o Rb mp Go O GO o RM ar 4 i64  :0,64,128, 
i i i i i i i i i i i DER 
caer Se Rp fo EG Co Gm Ge ie RE i32 i 0,32,64,96, 
i i i i i i i i i i i S128 160... 
mnow -i -1 1 1 Go 0 o %0 6 6 0626 
: E E E E 5 : E E E É : 63, 80, 96... 
Tigao Sk Ro Go ES SD Go Do Rr Ee em 6 i 0,8,16, 24, 
i i i i i i i i i i i : 32, 40, 48... 
Tes O ie a eee RR 04612 
: : : : : : z x . : : i 16, 20, 24, 
i 28... 
(Ge, Bl GO RD Ao = Ga cio O do Epa a HD 204/68, 
x : : 3 : : a nr : : : i 10, 12, 14, 
É 16... 
Mite Wilt) we toe ee need ETs O56Nn Oh 3 4 
i i i : i i i i i i : 5,6,7,8,9, 
i 10... 


Figura 3.34 Essa tabela se aplica para o cálculo de máscara de qualquer octeto do endereço IPv4 da rede 

Tabela de sub-redes 
para cálculo pelo 
método binário. 


que se deseja dividir em sub-redes. Vamos explicar a utilização da tabela para a rede 
200.130.26.0/24, onde se deseja dividir o 4° octeto apenas, pois se trata de uma rede classe 


C, endo podemos modificar os 3 primeiros octetos do prefixo de rede: 200.130.26. 


Vamos explicar primeiro o cabeçalho da tabela. Os bits do octeto estão numerados de 

1 (bit menos significativo) ao bit 8 (mais significativo), com seus respectivos pesos para o 
cálculo do valor da máscara em decimal. As demais colunas representam o valor em decimal 
da máscara binária (útil para a configuração das interfaces), a quantidade de sub-redes que 
teremos, a quantidade de hosts/sub-redes e, finalmente, a identificação das sub-redes. 


Note que a quantidade de sub-redes multiplicada pela quantidade de hosts/sub-redes dá 
sempre o valor 256, como já foi mostrado. 


Vamos explicar agora as linhas das máscaras. A primeira linha representa a situação de uma 
única sub-rede com 256 endereços, conforme mostra a Figura 3.29. Considerando o nosso 
exemplo de uma rede classe C, não teremos sub-redes, apenas a rede classe C original. Essa 
máscara pode representar sub-redes no caso de divisão de uma rede classe B ou uma rede 


classe A, mas não veremos esses casos neste momento. 


A segunda linha representa uma divisão em duas sub-redes, conforme mostra a Figura 3.30. 
Note que esta possibilidade de divisão não pode ser usada na arquitetura classful, que proíbe 
explicitamente “1 bit subnet” (sub-rede de 1 bit). 
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Aterceira linha representa uma divisão em 4 sub-redes, conforme mostrado na Figura 3.31. 
Note que, apesar de não ser obrigatório, os bits de sub-rede estão sempre mais à esquerda 
do que os bits de estação, conforme recomendação do RFC 950, página 6. E assim por 
diante, até a última linha que representa 256 sub-redes (só tem sentido para redes classes 
A e B). Note que, no nosso exemplo de rede classe C, só podemos ter máscara de 30 bits, no 


máximo, porque precisamos de 2 bits para estação, no mínimo. 
Vamos agora fazer um exemplo de cálculo com essa tabela binária. 


Seja uma rede classe C: 200.130.26.0/24, que desejamos dividir em sub-redes tal que pos- 
samos endereçar redes físicas com 30 hosts no máximo em cada uma. Note que o problema 
pode ser proposto de duas maneiras: definindo uma quantidade máxima de hosts por 


sub-rede ou uma quantidade mínima de sub-redes. 


Já que o enunciado determina a quantidade de hosts/sub-rede, vamos calcular quantos bits 
de hosts precisamos para endereçar até 30 hosts. No caso, precisamos de 5 bits (2º = 32) para 
obter 32 endereços, lembrando que perdemos sempre dois endereços de host por sub-rede 
(um endereço para identificar a sub-rede e um para o broadcast da sub-rede). Teremos então 
3 bits para sub-rede (8-5=3). 


Verificando na tabela vemos que a máscara adequada é a 224, que nos dá 8 sub-redes com 
até 32 endereços em cada uma. Então a máscara em decimal será: 255.255.255.224 ou /27,e 
as sub-redes serão: 


200.130.26.0/27, 200.130.26.32/27, 200.130.26.64/27,..., 200.130.26.224/27. 


Note que, sem a tabela de sub-redes, este processo é muito complicado e demorado, por se 
basear em cálculos binários. 


Método decimal 


oa Dada uma rede classe C 200.130.26.0/24. 

a Deseja-se 30 endereços por sub-rede. 

a 5 bits de hosts: 2º = 32 endereços/sub-rede. 

a A máscara em decimal é: 256 - 32 = 224. 

o 3bitsdesub-rede:8-5=3. 

a Máscara em contagem de bits: 24 + 3 = 27. 

o ID sub-redes: 0, 0 + 32 = 32, 32 + 32 = 64, ..., 224. 

Vamos calcular o mesmo exemplo, agora em decimal, sem usar a tabela de sub-redes. 
Vamos ver este processo passo a passo. 

1. O primeiro passo é determinar quantos bits de hosts precisamos; no caso, 5 bits. 

2. Em seguida calculamos quantos endereços podemos usar com 5 bits: 2° = 32 endereços. 
3. Em seguida calculamos a máscara em decimal: 256-32= 224. 

4. Calculamos agora a quantidade de bits de sub-redes: 8-5=3. Teremos então 8 sub-redes (23=8). 
5. Calculamos agora a máscara de sub-rede em bits: 24+3=27. 


6. Finalmente, calculamos as identificações das sub-redes: 0, 0+32=32, 32+32=64, 64+32=96, 


etc, lembrando que a última sub-rede terá a mesma identificação da máscara decimal: 224. 


Tradução de endereço 
de rede. Padrão oficial da 
IETF especificado pelo 
RFC 1631, habilita uma 
LAN a usar um grupo 

de endereços IP para 
tráfego interno e outro 
para tráfego externo. Um 
servidor NAT localizado 
onde a LAN “enxerga” a 
internet se faz neces- 
sário para a tradução dos 
endereços IP. 


Lembramos que o endereço de broadcast de cada sub-rede será sempre o endereço 
anterior ao da próxima sub-rede. Por exemplo, o endereço de broadcast da sub-rede 
200.130.26.32/27 será 200.130.26.63/27, porque a próxima sub-rede será 200.130.26.64/27. 


> 2 
Exercício de fixação 3 _G 
Verificando o endereço IP 


Alguns sites oferecem o serviço de verificação de sua conexão à internet. Com eles é pos- 
sível descobrir o endereço IP que você está utilizando. Não é necessariamente o endereço 
da sua estação, porque sua instalação pode estar usando servidores Network Address 


Translation (NAT) ou proxy, que “mascaram” o seu endereço verdadeiro. 


1. Acesse www.meuip.com.br e anote o seu endereço IP. 


Observe se o endereço IP confere com o mostrado no comando ipconfig e também com o 


nome do host. São oferecidos também diversos serviços adicionais. 


O nome do host é “IP Reverso”, porque é obtido através de uma consulta do tipo PTR ao ser- 
vidor DNS (informa o IP e obtém o nome). Esse tipo de consulta é chamado de DNS Reverso. 
As consultas normais DNS são do tipo A (informa o nome e obtém o IP). 


2. Acesse www.ipok.com.br e observe se o endereço IP também confere. Ainda são 


oferecidos outros serviços adicionais. 


3. Acesse www.simet.nic.br para testar a sua conexão. 
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E2 Roteiro de Atividades 3 


Atividade 3.1 - Validade de endereços 


O administrador de rede de uma instituição comercial tentou configurar alguns endereços 
para as interfaces de rede de um roteador. Os endereços testados foram: 200.150.256.10, 
100.1.1.10, 150.200.15.300 e 192.168.10.1.1. Considere que o administrador sabe usar os 
comandos de configuração de interface. Quais destes endereços podem ser configurados 


com sucesso e quais não podem ser configurados? Explique. 


























Atividade 3.2 — Atribuição de endereços 


Uma determinada instituição educacional está configurando uma inter-rede composta por 
três redes físicas, interligadas por dois roteadores. A topologia dessa rede é apresentada a 
seguir. Essa instituição solicitou três endereços de rede às autoridades da internet. 





1. Indique um possível conjunto de endereços atribuídos à instituição. 




















2. Agora, para cada rede, indique o endereço de rede e de broadcast. 
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3. Por fim, para cada estação, indique um possível endereço IP. 














Atividade 3.3 - Expansão da rede 


Um grande projeto criou uma demanda de expansão da rede na instituição educacional (Ativi- 
dade 3.2). Para isso, o administrador realizou um levantamento da demanda de novos pontos 
de rede e identificou que as redes N1, N2 e N3 devem comportar 500, 100 e 280 estações, res- 
pectivamente. Os endereços que foram anteriormente alocados para essas redes comportam 
essa quantidade de estações? Se não, indique um possível conjunto de endereços que possa 
ser usado para essas redes. Agora, para cada rede, indique o endereço de rede e de broad- 
cast. Em seguida, informe o intervalo de endereços permitidos para cada rede. 















































Atividade 3.4 - Configuração de endereços IPv4 


Dada a rede da Figura 3.35 desenhada no simulador de rede Netsimk (www.netsimk.com), 
composta de 3 roteadores (R1, R2 e R3), 4 switches, 2 consoles de roteadores e 12 compu- 
tadores, os alunos devem planejar o endereçamento IPv4 de todas as interfaces de rede 
configuráveis (roteadores e computadores), efetuar a configuração com endereços IPv4 e 


fazer os testes de conectividade. A rede chama-se Rede Atividade3 4.nsw. 













R1 
| ~+@— EO je SO DC Fm SO ie EO 
S1 

DCE 






































Figura 3.35 O planejamento dos endereços IPv4 deve seguir o seguinte roteiro: 
Planejamento de 


endereços IPv4. 4, A rede classe C 172.16.20.0/24 é fornecida para configuração de todas as interfaces de rede. 


2. Se necessário, calcule as sub-redes para todas as redes físicas. Para isso, é preciso pri- 
meiro determinar, analisando a figura, quantas redes físicas existem. Se você tiver dúvida, 


peça ajuda. Escolha o método mais conveniente de cálculo. 


3. Após calcular as sub-redes, primeiro defina os endereços IPv4 de cada interface dos rote- 
adores, porque eles serão os respectivos gateway padrão dos computadores das redes 1, 


2,3 e 4. Em seguida, defina os endereços IPv4 de cada computador. 


4. Concluído o planejamento, faça as configurações das interfaces, seguindo as orientações de 


uso dos comandos do simulador Netsimk. Carregue a rede Rede Atividade3 4.nsw no simulador. 


Ñ Capitulo 3- Roteiro de Atividades 


111 


Arquitetura e Protocolos de Rede TCP-IP 


X 


= 
= 
N 


5. Observe que as interfaces Ethernet dos roteadores são identificadas pela letra “E” 
seguida do número da interface (0 ou 1) e as interfaces seriais (conexão entre roteadores) 
são identificadas pela letra “S” seguida do número da interface (0 ou 1). 


6. Completadas as configurações, tente a conectividade entre as diversas redes com os 
comandos ping e tracert (traceroute). Siga a orientação do instrutor, escolhendo um com- 


putador de cada rede para teste. 


Atividade 3.5 — Entrega direta e indireta 


Para realizar a entrega de datagramas, sabemos que a arquitetura TCP/IP suporta o conceito 


de entrega direta e indireta. Considere a rede apresentada na Figura 3.36. 











192.168.10.1 192.168.30.1 
1:1:1:1:1:1 3:3:3:1:1:1 
R1 R2 


192.168.10.3 Š To 192.168.20.1 192.168.20.2 47. 192.168.30.3 








1:1:1:3:3:3 o 2:2:2:1:111 2:2:2:2:2:2 o 4 “+ 3:3:3:3:3:3 
192.168.10.2 192.168.30.2 
1:1:1:2:2:2 3:3:3:2:2:2 
1. Suponha que a estação E1 enviou um datagrama para a estação E2. Como as duas uia 3.36 
Rede da 
estações estão conectadas na mesma rede física, certamente, o mecanismo de entrega atividade 3.5 


direta foi usado. Identifique os endereços IP de origem e destino informados no data- 
grama. Além disso, para ser efetivamente transmitido, o datagrama é encapsulado em 
um quadro da rede física. Identifique os endereços físicos de origem e destino infor- 


mados nesse quadro. 


























2. Suponha que a estação E1 enviou um datagrama para a estação E3. Como essas esta- 
ções não estão conectadas na mesma rede física, certamente o mecanismo de entrega 
indireta foi adotado. Identifique os endereços IP de origem e destino informados no 
datagrama. Esses endereços mudam à medida que o datagrama é encaminhado entre os 
roteadores intermediários? Explique. Além disso, em cada rede intermediária, o data- 
grama é encapsulado em um quadro daquela rede física. Identifique os endereços físicos 


de origem e destino informados nos quadros de cada rede intermediária. 





























Figura 3.37 

Rede da 
Atividade 3.6 
configurada 
no Netsimk. 


Atividade 3.6 — Protocolo ARP 


Nesta atividade, vamos usar a rede com o nome: Rede Ati 


vidade3 6.nsw. Foi adicionada 


uma rota estática em cada roteador (R1 e R2), conforme mostrado na tabela de rotas: 


S (rota estática), C (rede diretamente conectada). 


C 192.168.10.0/24 E0 O 
C 192.168.20.0/24 E1 0 
S 192.168.30.0/24 E1 0 


<i + 
— Fa0/1-~ =p Fa0/2— E0 SD qu E1 ——— 
z3 y a 
N2 R2 O 


Inicialmente a tabela ARP da estação E1 está vazia, porque 


S 192.168.10.0/24 E0 0 


C 192.168.20.0/24 E0 0 
C 192.168.30.0/24 E1 O 





não foi preciso enviar nenhum 


pacote para outra máquina da rede. Isso pode ser verificado através do comando arp -a na 


janela DOS em E1, conforme abaixo: 

Carp =a 

No ARP entries found 

Após os seguintes comandos: 

Coping 192. 16810,2 
Pinging 192.168.10.2 with 32 bytes of data: 
Reply from 192.168.10.2 on Eth, time<l0Oms TT 
Reply from 192.168.10.2 on Eth, time<l0Oms TT 


Reply from 192.168.10.2 on Eth, time<l0Oms TT 





[L=128 


Eiza 


[L=128 





Reply from 192.168.10.2 on Eth, time<l0Oms TT 


Cerone BZ, ioe. $0. il 

Pinging 192.168.30.1 with 32 bytes of data: 
Ping request timed out. 

Ping request timed out. 


Reply from 192.168.30.1 on Eth, time<10ms 








Reply from 192.168.30.1 on Eth, time<10ms 


[L=128 


THEIL 





TTL 
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A tabela ARP ficou assim: 


C:>arp -a 
Internet Address Physical Address Type 
LIZ Mos 10.2 El-5E-DF -00-10-03 Dynamic 
192.168 OS: F7-BB-34-00-10-04 Dynamic 


Vemos que aparecem os endereços MACs e respectivos endereços IPs da estação E2 e da 
interface EO do roteador R1, que é o gateway padrão da rede N1 onde está a estação E1. 
No primeiro ping houve uma entrega direta, e no segundo ping uma entrega indireta, daí a 
necessidade de passar o pacote através do roteador R1. 


Para melhor visualização da rota usada pelo ping no segundo caso, vamos usar um recurso 
do simulador muito útil nesses casos. 


Procedimento: 


1. Selecione no menu superior a opção “Teaching/Demonstrate PING progress on displayed 
routing tables...” 


2. Clique no botão “Continue” na janela de diálogo. 


3. Execute novamente o ping na janela DOS e aperte a barra de espaço para visualizar o 
caminho de ida e volta. 


Depois de algum tempo sem tráfego, as entradas da tabela ARP são descartadas (flushed) e 


a tabela ARP fica vazia novamente. 


Atividade 3.7 — Tabela ARP 


Sabemos que o protocolo ARP mantém uma tabela para tornar a resolução de endereços 
mais eficiente. 


1. Identifique as entradas da tabela ARP de sua estação. 











2. Observando a tabela ARP, escolha outra estação do laboratório que não conste nessa 
tabela. Perguntando aos membros do grupo que estão trabalhando nela, identifique e 


anote o endereço IP dessa outra estação. 











3. Considerando que o endereço da estação escolhida é X, execute o comando ping X. 


Lembre-se de substituir X pelo endereço IP da estação escolhida. 











4. Identifique novamente as entradas da tabela ARP de sua própria estação. Alguma entrada 


foi adicionada? Qual? 











5. Sabendo que o comando ping enviou datagramas de sua estação para a outra estação 


selecionada, explique o que provocou a mudança na tabela ARP. 











Atividade 3.8 — Modificando a tabela ARP 


As entradas da tabela ARP permanecem válidas durante certo intervalo de tempo. No 


entanto, o administrador pode remover entradas existentes ou incluir novas entradas. 


1. Remova a entrada da tabela ARP associada à estação selecionada na atividade anterior. 


Verifique se a entrada foi realmente removida. 











2. Escolha outra estação, diferente daquela selecionada na atividade anterior. Perguntando 
aos membros do grupo que estão trabalhando nessa outra estação, identifique e anote o 


endereço IP e o endereço físico dela. 











3. Inclua uma nova entrada na tabela ARP que mapeia o endereço IP dessa nova estação sele- 


cionada para o seu respectivo endereço físico. Verifique se a entrada foi realmente incluída. 











Atividade 3.9 - Servidores DHCP 


Conforme visto, os protocolos para configuração automática de endereços IP se utilizam de 
broadcast. O que você imagina que pode acontecer se uma única rede possuir mais de um 
servidor DHCP? 
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Enderecamento IP (parte 2) 








Apresentar o tratamento de endereços de super-redes, incluindo atribuição, agregação 





e subdivisão de blocos de endereços. Descrever o processo de cálculo de sub-redes 


com máscara de tamanho variável (VLSM), e o processo de tradução de endereços 


objetivos 







privados (NAT), além de introduzir o endereçamento IPv6 e sua necessidade. 


Super-redes ou blocos de endereços, CIDR e VLSM, endereços privados e tradução 
NAT, conceitos básicos de endereçamento IPv6. 


SO}99U09 





Super-redes 


Este capítulo trata do conceito de super-redes ou blocos de endereços, CIDR e VLSM. 

A padronização do esquema de endereçamento de sub-redes permitiu um melhor aprovei- 
tamento do espaço de endereçamento IP. No entanto, mesmo com o conceito de sub-redes, 
o IETF percebeu que a atribuição de endereços classe B ainda representava um enorme 
desperdício de endereços. 


Por exemplo, na Figura 4.1, apenas quatro endereços de sub-redes foram usados da rede 
classe B original: 172.16.0.0/16. Embora os demais endereços de sub-rede (172.16.5.0/24 
até 172.16.255.0/24) ainda possam ser atribuídos para outras redes físicas que venham a 
existir naquela instituição, esses endereços de sub-rede não podem ser atribuídos a outras 
instituições, representando assim um grande desperdício do espaço de endereçamento. 
Consequentemente, de forma bastante rápida, os endereços de rede classe B começaram a 
se tornar escassos. 


R 
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Endereçamento de super-redes 


o Permitem o uso de diversos endereços de rede nas várias redes de uma instituição. aa 
o Atribuem quantidade de endereços adequada às necessidades da instituição. 
a Evitam a atribuição de endereços classe B. 
m Atribuem blocos de endereços: 
a Conjunto de endereços classe C. 
a Partes de um endereço classe A, B ou C. 
m Bloco deve comportar o número de estações da instituição. 
a Bloco de endereços é um conjunto contíguo de endereços. 
m Tamanho é potência de 2. 
m Satisfaz a algumas restrições adicionais. 
Endereços são formados por um prefixo de bloco e um identificador de estação: 
ao Endereço pode ter número variado de bits no prefixo de bloco. 
a Invalida o conceito de classes A, Be C. 
a Identificador de estação define o tamanho do bloco de endereços. 


Avaliando o uso ineficiente dos endereços classe B, pode-se perceber que a principal razão é 
a inexistência de uma classe de rede de tamanho adequado para a maioria das instituições. 
Por um lado, um endereço classe C, com no máximo 254 estações, é muito pequeno para 
diversas instituições. Por outro lado, um endereço classe B, que permite até 65.534 esta- 


ções, é muito grande e gera um uso ineficiente do espaço de endereçamento. 


Como resultado, por um lado, a realidade alguns anos atrás era que apenas uma pequena 
parcela dos endereços classe C estava atribuída. Por outro lado, uma parcela considerável 
dos endereços classe B já estava atribuída. Para piorar a situação, existem milhões (22!) de 


endereços classe C e apenas alguns milhares (2'*) de endereços classe B. 


Na época, por conta desta constatação, ao invés de criar uma nova classe de endereços, o 


IETF instituiu e padronizou um novo esquema de endereçamento, denominado end t 





de super-redes, que adota o caminho inverso do esquema de sub-redes. Ou seja, ao 
invés de usar um único endereço de rede para múltiplas redes físicas de uma instituição, o 
esquema de super-redes permite o uso de diversos endereços de rede nas várias redes de 
uma única instituição. 


Por exemplo, considere uma instituição com aproximadamente 3 mil estações que, no 
esquema original de endereçamento, requeira um endereço classe B. No entanto, adotando 
o esquema de super-redes, ao invés de atribuir o endereço classe B, pode ser atribuído um 
bl 





Esse bloco deve ser grande o suficiente para permitir o endereçamento das 3 mil estações 
existentes na instituição. Logo, um bloco de 16 endereços classe C, que possui aproximada- 
mente 4.096 endereços disponíveis, é suficiente para essa instituição endereçar todas as suas 
estações e ainda ter uma reserva para eventual necessidade futura, sem o desperdício do uso 
de uma classe B. Observe que o esquema de super-redes conserva os endereços classe B, que 
já eram quase escassos, e atribui endereços classe C, que ainda eram relativamente disponi- 


veis na época da padronização do esquema de endereçamento de super-redes. 


No esquema de super-redes, o prefixo de rede é, agora, denominado prefixo do bloco, 


Endereçamento 
de super-redes 





Esquema de endereça- 
mento da arquitetura 
TCP/IP que permite a 
atribuição de blocos de 
endereços, cujos tama- 
nhos são adequados 
as necessidades das 
instituições. 


Bloco de endereços 


Conjunto de ende- 
reços contíguos, cujo 
tamanho é potência 
de 2, alocados a uma 
instituição. 


Prefixo do bloco 


Porção do endereço IP 
que identifica um bloco 
de endereços. 


Tamanho do bloco 


Quantidade de ende- 
reços consecutivos que 
compõem um bloco de 

endereços. 


enquanto o identificador de estação mantém a mesma designação. Por exemplo, o bloco de 
4.096 (2'2?) endereços possui 20 bits no prefixo do bloco e 12 bits no identificador de estação. 


um identificador de estação de n bits define um bloco de 2" endereços. 


Embora o exemplo tenha usado um bloco de 16 endereços classe C, na prática, o esquema 
de endereçamento de super-redes não está restrito a blocos de endereços de uma classe 
determinada. Na verdade, um bloco de endereços pode ser qualquer conjunto de endereços 
contíguos, cujo tamanho seja potência de 2 e satisfaça a algumas restrições adicionais. Por 
exemplo, podem existir blocos de 512, 1024 e 2.048 endereços. Além disso, o tamanho de 
um bloco pode ser menor ou igual a 256, que é o total de endereços em uma rede classe C. 


Portanto, podem existir blocos de 16, 64, 128 e 256 endereços. 


Consequentemente, no esquema de endereçamento de super-redes, o prefixo de bloco 
(prefixo de rede) pode possuir um número variado de bits, não impondo qualquer relação 
com o número de bits do prefixo de rede de endereços classe A, B ou C. Diz-se, então, que o 
endereçamento de super-redes não obedece à definição de classes de endereços. Logo, no 


esquema de super-redes, as classes A, B e C deixam de existir (classless). 


CIDR 


Ea 
Classless Inter-Domain Routing (CIDR) é uma técnica que especifica um esquema de ende- 
reçamento e roteamento que adota blocos contíguos de endereços, ao invés de endereços 
classe A, Be C. Esta técnica minimiza o desperdício de endereços e permite a atribuição de 


blocos de endereços com tamanho adequado às necessidades da instituição. 


O esquema de endereçamento de super-redes é proposto em conjunto com uma técnica 
denominada Classless Inter-Domain Routing (CIDR), que, como o próprio nome sugere, 
invalida o conceito de classes de endereços, pois o tamanho dos blocos de endereços é 
completamente independente dos endereços de classe A, Be C, o que caracteriza a arqui- 
tetura classless. Por enquanto, é suficiente entender que o endereçamento de super-redes 
pode minimizar o desperdício de endereços, pois permite a atribuição de blocos de tama- 
nhos adequados às necessidades das instituições. Trataremos aqui do endereçamento de 


super-redes e nas regras para criar, representar e usar blocos de endereços. 


Blocos de endereços 


Bloco de endereços é um conjunto contíguo de endereços, cujo tamanho é potência de 2. à 


Os blocos de endereços não possuem qualquer relação com as classes A, B e C. | 


O endereçamento de super-redes minimiza o desperdício de endereços, atribuindo blocos 
de endereços, cujos tamanhos são adequados às necessidades das redes físicas das institui- 
ções. Assim, pequenos blocos são atribuídos a pequenas redes físicas e grandes blocos são 
atribuídos a grandes redes físicas. 


No esquema de endereçamento de super-redes, um bloco de endereços é um conjunto de 
endereços contíguos, cujo tamanho é potência de 2. Por exemplo, um bloco de 4.096 (212) 
endereços pode ser atribuído a uma instituição que possua 3 mil estações. Observe que, 
no esquema de endereçamento IP original, um endereço classe B seria requerido por essa 
instituição. Considerando que um endereço classe B possui 65.534 endereços permitidos, o 
desperdício seria de 62.534 endereços. No entanto, a atribuição do bloco de 4.096 ende- 
reços reduz este desperdício para apenas 1.096 endereços. 
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Como os blocos de endereços não possuem qualquer relação com as classes de endereços 
do esquema de endereçamento IP original, um bloco de endereços pode conter diversos 
endereços de rede classe A, B ou C, assim como pode conter apenas uma fração de um 
endereço classe A, B ou C. Consequentemente, blocos de diferentes tamanhos podem ser 
atribuídos; por exemplo: 16, 128, 512, 2.048 e 8.192. 


Hierarquia de endereçamento 


Para prover a flexibilidade de diferentes tamanhos de blocos, os endereços IP adotam uma 
estrutura hierárquica que identifica as redes físicas às quais os blocos estão alocados e as 
estações (interfaces) nessas redes. 

Y 
A representação dessa hierarquia é realizada com a divisão dos endereços IP em duas partes: c] 


o Identificador de bloco - denominado prefixo do bloco, prefixo de rede ou prefixo IP, 


serve para identificar a rede física à qual o bloco está alocado, de forma única e individual. 


o Identificador de estação - identifica a estação (interface) dentro da rede (bloco) de 
forma única e individual. 


A Figura 4.2 ilustra a estrutura hierárquica dos endereços IP no esquema de endereça- 


mento classless. 


0 31 


Figura 4.2 
Identificador de bloco Identificador de estação Hierarquia de 
endereçamento. 
Por exemplo, um bloco de 4.096 (2!) endereços possui 20 bits no prefixo do bloco e 12 bits 
no identificador de estação. Como o tamanho do bloco é função do número de bits do iden- 
tificador de estação, um identificador de estação de n bits define um bloco de 2" endereços, 
conforme mostrado na Figura 4.3. 
Identificador n Endereços ; 
de estação =—> 2 do bloco Figura 4.3 


Bloco de endereços. 


A estrutura hierárquica de um bloco é aparentemente idêntica àquela adotada no esquema 
de endereçamento IPv4 original. No entanto, no esquema original, o prefixo de rede sempre 
possui 8, 16 ou 24 bits, requeridos pelos endereços classe A, B ou C, respectivamente. Por 
outro lado, nos blocos de endereços, o prefixo do bloco pode possuir qualquer número de 
bits (exceto em alguns casos especiais) e não tem qualquer relação com o número de bits do 
prefixo de rede de endereços classe A, B ou C. 


Máscara do bloco 

A máscara de bloco delimita a posição do prefixo de bloco e do identificador de 
estação. Representação: 

o Padrão de 32 bits. 

a Possui bits 1 no prefixo de bloco. 

ao Possui bits O no identificador de estação. 


Para delimitar os bits que compõem o prefixo do bloco e o identificador de estação, o esquema 
de endereçamento de super-redes define o conceito de máscara de bloco, que representa 


uma simples adaptação do conceito de máscara de rede do endereçamento IPv4 original. 


Figura 4.4 
Mascara do bloco. 


Figura 4.5 
Endereço de bloco. 


A máscara de bloco também é um padrão de 32 bits, contendo bits 1 na posição do prefixo 
do bloco e bits O na posição do identificador de estação. A Figura 4.4 ilustra a estrutura de 


uma máscara de bloco. 


T+ ME 


As máscaras de bloco também podem ser escritas com a notação decimal (dotted-decimal 
notation) ou contagem de bits (bit count). Porém, na prática, a notação de contagem de 
bits é mais adotada. A seguir, um exemplo de bloco de endereço e a respectiva máscara 
nas notações decimal e contagem de bits. Neste caso, o prefixo do bloco é 200.10, pois a 
máscara possui 16 bits. 


a Decimal- 200.10.0.0 255.255.0.0 
o Contagem de bits - 200.10.0.0/16 


Neste mesmo exemplo, pode-se observar que seria inválido no esquema de endereçamento 
IPv4 original, pois 200.10.0.0 é um endereço classe C que deve ter uma máscara de pelo 
menos 24 bits. Considerando que o prefixo do bloco pode possuir um número variado de 
bits, sem qualquer relação com o número de bits do prefixo de rede de endereços classe 

A, B ou C, os blocos 20.0.0.0/24, 150.0.0.0/8, 200.10.0.0/20 e 192.100.1.0/27 são válidos no 
esquema de endereçamento de super-redes. 


Vale ressaltar que, na prática, o termo máscara de rede também é usado com o mesmo sig- 
nificado de máscara de bloco, porque, geralmente, o contexto em que o termo é usado torna 
óbvio o tipo de máscara tratada. 


Endereço de bloco e de broadcast 


a 
o Endereço de bloco - pode ser utilizado para referenciar a rede física à qual o bloco 
está associado. 


o Endereço de broadcast direto - permite o envio de datagramas para todas as 
estações do bloco. 


Assim como no esquema de endereçamento IPv4 original, em que endereços de rede 
podem ser usados para referenciar as redes físicas, no esquema de endereçamento de 
super-redes, endereços de bloco podem ser usados para referenciar as redes físicas às quais 
os blocos são atribuídos. O endereço de bloco é denominado endereço base do bloco. 


No esquema de endereçamento IPv4 original, o endereço de rede é representado pelo 
prefixo de rede e pelo identificador de estação, este último com todos os bits iguais a 0. 
De forma análoga, no esquema de endereçamento de super-redes, o endereço de bloco é 
representado pelo prefixo de bloco e pelo identificador de estação, este último com todos 
os bits iguais a 0. Assim, o identificador de estação, cujos bits são iguais a 0, é reservado e 
nunca atribuído a qualquer interface de uma rede física. A Figura 4.5 ilustra a convenção 
para endereços de bloco. 
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Por exemplo, se uma estação possui o endereço IP 200.10.16.1/16, então o endereço do bloco é 
200.10.0.0, pois o identificador de estação possui 16 bits. Uma vez que cada rede física possui 
um endereço de bloco particular, o conceito de broadcast direto também pode ser adotado, 
permitindo o envio de datagramas IP para todas as estações (interfaces de estações e rotea- 
dores) de um determinado bloco a partir de qualquer estação da inter-rede TCP/IP. 


No esquema de endereçamento IPv4 original, o endereço de broadcast direto é represen- 
tado pelo prefixo de rede e pelo identificador de estação, este último com todos os bits 
iguais a 1. De forma semelhante, no esquema de endereçamento de super-redes, o ende- 
reço de broadcast direto do bloco é representado pelo prefixo de bloco e pelo identificador 
de estação, este último com todos os bits iguais a 1. Assim, o identificador de estação, cujos 
bits são iguais a 1, é reservado e nunca atribuído a qualquer interface da rede física. A Figura 
4.6 ilustra a convenção para endereços de broadcast direto de blocos. 


0 31 Figura 4.6 


identificador de bloco Endereço de 
broadcast direto. 


Por exemplo, se uma estação possui o endereço IP 200.10.16.1/16, então o endereço de 
broadcast direto do bloco é 200.10.255.255, pois o identificador de estação possui 16 bits. 


Espaço de endereçamento e endereços permitidos 


a 
Espaço de endereçamento é um conjunto de endereços que compartilham um mesmo 


prefixo de bloco. Os endereços permitidos formam um conjunto de endereços que 
podem ser atribuídos às interfaces. 


Considerando um determinado endereço de bloco, o espaço de endereçamento é composto 
por todos os endereços que podem ser expressos com variação do identificador de estação. 


Identificador n Espaço de Figura 4.7 
de estação e 2 endereçamento Espaço de 
endereçamento. 


Por outro lado, os endereços permitidos são todos aqueles que podem ser atribuídos às 
interfaces de estações e roteadores. 


Figura 4.8 
Identificador n Endereços e o 
de estação m 2 -2 usáveis P p 

interfaces. 


Portanto, os endereços permitidos representam todo o espaço de endereçamento, exceto 
o primeiro (endereço de bloco) e o último (endereço de broadcast direto do bloco). Logo, se 
um determinado bloco possui n bits no identificador de estação, então esse bloco possui 2" 


endereços e 2" - 2 endereços permitidos. 


Por exemplo, considere o bloco 200.10.16.0/20, que possui 20 bits no prefixo de bloco e 12 bits 
no identificador de estação. Podemos afirmar que esse bloco possui 4.096 (21?) endereços e 
4.094 (212 - 2) endereços permitidos. A Figura 4.9 ilustra um espaço de endereçamento. 

Como esses endereços são gerados pela combinação de valores no identificador de estação, 
o espaço de endereçamento do bloco 200.10.16.0/20 compõe o intervalo de 200.10.16.0 até 
200.10.31.255, ao passo que os endereços permitidos desse bloco compõem o intervalo de 
200.10.16.1 até 200.10.31.254. 


Figura 4.9 
Espaço de 
endereçamento. 
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mesma rede fisica. 


a Um único identificador de estação deve ser atribuído a cada interface conectada a 


uma determinada rede física. 
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200.10.16.0/20 150.10.1.0/24 


200.10.16.1 





R1 
> Ao 
200.10.16.0/20 + 150.10.1.3 


Figura 4.10 
Atribuição de 
200.10.16.2 150.10.1.2 endereços. 





Observe o detalhamento a seguir: 


a Na rede N1, as estações (E1 e E2) e o roteador (R1) pertencem ao bloco 200.10.16.0/20; na 
rede N2, as estações (E3 e E4) e o roteador (R1) pertencem ao bloco 150.10.1.0/24. 


o Na rede N1, as estações (E1 e E2) e o roteador (R1) possuem os identificadores de estação 
1,2 e 3, respectivamente; na rede N2, as estações (E3 e E4) e o roteador (R1) possuem os 


identificadores de estação 1,2 e 3, respectivamente. 


Observe que interfaces conectadas a diferentes redes físicas podem possuir os mesmos 
identificadores de estação, pois seus prefixos de bloco são diferentes e asseguram a unici- 
dade de endereços. 


Subdivisão de blocos 


a A subdivisão de blocos de endereços em sub-blocos forma as sub-redes. 
a Subdivisão é realizada pelo deslocamento da máscara original para a direita. 


a Cada sub-bloco pode ser atribuído a uma rede física. 


Implementações do protocolo IP que suportam a arquitetura classless permitem a adoção 
do endereçamento de super-redes, como também o endereçamento de sub-redes. Embora, 
originalmente, o termo sub-rede tenha surgido como a possibilidade de subdividir um ende- 
rego de rede classe A, B ou C em endereços de sub-rede, após a padronização do esquema 


Subdivisão de 
de endereçamento classless, o termo sub-rede também se refere à subdivisão de um bloco um bloco 





de endereços em blocos menores. Na arquitetura classless, sub-redes são denominadas Processo no qual um 
bloco de endereços 

é dividido em um 
conjunto de blocos 
menores (sub-blocos). 


como sub-blocos. 


Por exemplo, o bloco 200.10.16.0/20, que possui 4.096 (2!2) endereços, pode ser subdividido em 
8 sub-blocos de 512 (2º) endereços. A Figura 4.11 ilustra conceitualmente o processo de subdi- 


visão. Cada sub-bloco de 512 endereços constitui uma sub-rede do bloco de 4.096 endereços. Sub-bloco 


Conjunto de endereços 
contíguos obtidos 

a partir da subdivisão 
de um bloco de 
endereços maior. 


Figura 4.11 


Exemplo de subdi- 
visdo de blocos. 


Figura 4.12 


Subdivisdo de blocos. 


oi 
N 


0 31 


11001000 00001010 0001 0000 00000000 200.10.16.0/20 
i 1 23 
11001000 00001010 0001 (000) 0 00000000 200.10.16.0/23 


11001000 00001010 0001 001 0 00000000 200.10.18.0/23 


11001000 00001010 0001 010 0 00000000 200.10.20.0/23 


11001000 00001010 0001 011 0 00000000 200.10.22.0/23 


11001000 00001010 0001 100 0 00000000 200.10.24.0/23 


11001000 00001010 0001 101 0 00000000 200.10.26.0/23 


11001000 00001010 0001 110 0 00000000 200.10.28.0/23 





11001000 00001010 0001 111 0 00000000 200.10.30.0/23 


Para criar sub-blocos, é preciso manipular a máscara do bloco original, deslocando-a para a 
direita. O número de bits deslocados determina o número de sub-blocos criados. Generali- 


zando, se um deslocamento de n bits é realizado na máscara, então 2" sub-blocos são criados. 


Por exemplo, na Figura 4.11, a máscara original foi deslocada de 3 bits, criando 8 (2?) sub-blocos. 


Deslocamento 


| 


n Número de 
2 sub-blocos 


Em seguida, para cada combinação, basta escrever o valor do endereço do sub-bloco e 


X Capítulo 4- Endereçamento IP (parte 2) 


125 


NE Arquitetura e Protocolos de Rede TCP-IP 


126 


Sub-bloco 

200.10.16.0/23 
200.10.18.0/23 
200.10.20.0/23 
200.10.22.0/23 
200.10.24.0/23 


200.10.26.0/23 


Espaço de endereçamento 
200.10.16.0 - 200.10.17.255 
200.10.18.0 - 200.10.19.255 
200.10.20.0 - 200.10.21.255 
200.10.22.0 - 200.10.23.255 
200.10.24.0 - 200.10.25.255 


200.10.26.0 - 200.10.27.255 


Endereços usaveis 

200.10.16.1 - 200.10.17.254 
200.10.18.1 - 200.19.23.254 
200.10.20.1 - 200.10.21.254 
200.10.22.1 - 200.10.23.254 
200.10.24.1 - 200.10.25.254 


200.10.26.1 - 200.10.27.254 


Figura 4.13 

Tabela de 
endereços dos 
sub-blocos do bloco 
200.10.16.0/20. 


200.10.28.0/23 200.10.28.0 - 200.10.29.255 200.10.28.1 - 200.10.29.254 


200.10.30.0/23 200.10.30.0 - 200.10.31.255 200.10.30.1 - 200.10.31.254 


Observe que os intervalos de endereços desses sub-blocos são contíguos. Além disso, 
o primeiro endereço do primeiro sub-bloco (200.10.16.0) e o último endereço do último 
sub-bloco (200.10.31.255) definem o espaço de endereçamento do bloco original 
200.10.16.0/20, mostrado na Figura 4.11. 


Agregação de blocos 


a 
Agregação de blocos é o processo de agregar blocos menores para compor um bloco maior, 


sendo um processo realizado pelo deslocamento da máscara original para a esquerda: 
a Blocos menores adotam a mesma mascara. 

o Total de blocos menores é potência de 2. 

a Blocos menores são idênticos em todos os bits, exceto em um conjunto contiguo. 


o Bits diferentes possuem todas as combinações possíveis. 


A partir do processo de subdivisão de blocos de endereços, podemos perceber que o pro- 
cesso inverso também é possível. Em outras palavras, ao invés de subdividir um bloco em 
blocos menores, podemos agregar diversos blocos menores para compor um bloco maior. 
Esse processo é denominado de agregação de blocos, em que vários blocos menores são 
combinados para compor um bloco de endereços maior. Por exemplo, os sub-blocos de 
23 bits da Figura 4.11 podem ser agregados no bloco 200.10.16.0/20. 


A agregação de blocos é possível somente quando os blocos disponíveis possuem as 


seguintes características em comum: 


a Os blocos disponíveis adotam a mesma mascara. 
o O número de blocos disponíveis é potência de 2. 


a Os endereços dos blocos disponíveis são idênticos em todos os bits, exceto em um con- 
junto contíguo desses bits. Nesse conjunto contíguo de bits diferentes, existem todas as 


combinações possíveis de valores. 


Veja na Figura 4.11 que os 8 (23) sub-blocos de 23 bits são idênticos, exceto em 3 bits con- 
tíguos, e, nesses bits, existem as 8 combinações possíveis de valores. Logo, os 8 blocos de 
23 bits podem ser agregados para compor um bloco maior. Em função dessas restrições, 
observe que 2 blocos devem diferir em um único bit, 4 blocos devem diferir em apenas 

2 bits, e assim por diante. Generalizando, se existem 2" blocos disponíveis, então esses 
blocos devem diferir em apenas n bits. 


Figura 4.14 
Agregação 
de blocos. 


É importante ressaltar que um conjunto de blocos pode ser agregado, mesmo que, 
® aparentemente, não atenda as restrições mencionadas anteriormente. No entanto, 
nesses casos, através de subdivisões ou agregações dos blocos disponíveis, sempre é 


possível obter um conjunto de blocos que atenda a todas as restrições mencionadas. 


Constatada a viabilidade da agregação, o endereço do bloco agregado é igual ao endereço 


20 23 31 


11001000 00001010 0001 0 00000000 200.10.16.0/23 


11001000 00001010 0001 001 0 00000000 200.10.18.0/23 


11001000 00001010 0001 010 0 00000000 200.10.20.0/23 


11001000 00001010 0001 011 0 00000000 200.10.22.0/23 


11001000 00001010 0001 100 0 00000000 200.10.24.0/23 


11001000 00001010 0001 101 0 00000000 200.10.26.0/23 


11001000 00001010 0001 110 0 00000000 200.10.28.0/23 





11001000 00001010 0001 111 0 00000000 200.10.30.0/23 


20: 


11001000 00001010 0001 0000 00000000 200.10.16.0/20 


Mascaras de tamanho fixo 


Sub-redes de um determinado endereço de rede devem usar máscaras idênticas. 


Comportam o mesmo número de estações. 


Roteamento assume que máscaras de um endereço de rede são idênticas. 


Máscaras de tamanhos diferentes podem gerar sérios problemas de roteamento. 


Não permitem a aplicação recursiva do conceito de sub-redes. 


Tamanho da máscara depende do número de redes físicas e do número de estações 


da maior rede física. 
Para definir a máscara: 


ao Escolha a maior máscara possível que comporte o número de estações da maior 


rede física. 


o Verifique se o número de sub-redes criadas atende ao número de redes físicas existentes. 





a Reserve espaço para crescimento futuro. 
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Na arquitetura classful, para cada endereço de rede classe A, B ou C, todas as sub-redes 
devem adotar a mesma máscara. Essa limitação é resultado da implementação da função 
de roteamento da arquitetura classful, que assume que as máscaras das sub-redes de um 
determinado endereço de rede são idênticas. Embora possível, a adoção de máscaras 
diferentes pode gerar sérios problemas de roteamento. Na literatura, o termo máscaras de 


Roteamento 


Processo de escolha 
dos caminhos (rotas) 


para enviar os data- 
gramas, permitindo que 
alcancem seus destinos 
finais, através de 
diversas redes e rotea- 
dores intermediários. 


Como consequência do uso de máscaras idênticas, as diversas sub-redes criadas possuem 
o mesmo número de endereços permitidos e, portanto, comportam o mesmo número de 
estações. Assim, o tamanho da máscara a ser usada depende do número de redes físicas 


existentes e do número de estações da maior sub-rede. 


No projeto de sub-redes, deve-se escolher a maior máscara possível que comporte o 
número de estações da maior rede física. Em seguida, deve-se verificar se o número de 
sub-redes criadas atende ao número de redes físicas existentes. Para permitir o cresci- 
mento futuro das redes físicas, é importante que o número de endereços permitidos, se 


possível, seja um pouco maior que o número de estações da maior sub-rede. 


O uso de máscaras idênticas também impõe outra limitação, pois não permite a aplicação 
recursiva do conceito de sub-redes. Assim, uma vez que um endereço de rede classe A, B ou 
C é dividido em um conjunto de endereços de sub-redes, estes últimos não podem sofrer 


outro processo de divisão. Por exemplo, na Figura 4.15, nenhuma das sub-redes pode ser 


2. 
< 
2 
o 
D 
© 
3 
wn 
E 
5 
x 
D 
o 
D 
wn 
3 
D 
5 
© 
el 
D 
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oO 
N 
Ww 


11000000 10101000 00000001 00000 192.168.1.0/27 


N 
N 
w 
= 


11000000 10101000 00000001 001 | 00000 | 192.168.1.32/27 


11000000 10101000 00000001 010 | 00000 | 192.168.1.64/27 


11000000 10101000 00000001 011 | 00000 | 192.168.1.96/27 

11000000 10101000 00000001 100 | 00000 | 192.168.1.128/27 

11000000 10101000 00000001 101 | 00000 | 192.168.1.160/27 

11000000 10101000 00000001 110 | 00000 | 192.168.1.192/27 Figura 4.15 
Exemplo de 
endereçamento 


11000000 10101000 00000001 111 | 00000 | 192.168.1.224/27 de sub-redës, 


Para reduzir o tamanho das tabelas de roteamento, o endereçamento de sub-redes esconde 
os detalhes da inter-rede interna de uma instituição. Em outras palavras, roteadores 

externos (qualquer roteador não conectado a alguma das sub-redes) não precisam conhecer 
rotas para cada sub-rede individual, mas apenas para o endereço de rede a partir do qual as 


sub-redes foram geradas. 


Por exemplo, na Figura 4.16, o roteador externo R4 conhece apenas a rota via R2 para o 
endereço de rede 192.168.1.0/24, ao invés de uma rota para cada endereço de sub-rede. 


O fato do endereço de rede 192.168.1.0/24 ser dividido em sub-redes é transparente para o 
roteador R4. Essa divisão em sub-redes foi uma decisão do administrador de redes da insti- 


tuição e é independente das redes externas. 


192.168.1.32/27 192.168.1.160/27 


192.168.1.96/27 192.168.1.128/27 


st VR LD A ah 


192.168.1.64/27 200.10.1.0/24 





192.168.1.192/27 


Figura 4.16 
Endereçamento 
de sub-redes. 


Vantagens: 

a Simplicidade no processo de criação de endereços de sub-redes. 
ao Facilidade de memorização dos endereços. 

Desvantagens: 

ao Desperdício de endereços. 

a Redução da flexibilidade da rede. 


a Limita o número de redes físicas. 





m Impõe redes físicas com quantidades semelhantes de estações. 


Com base no conhecimento de que as arquiteturas de endereçamento classful e classless 
suportam o conceito de sub-redes, podemos avaliar os diversos aspectos envolvidos na adoção 
de máscara de tamanho fixo ou máscara de tamanho variável no projeto de endereçamento. 


A adoção de máscaras de tamanho fixo torna o projeto de endereçamento bastante simples, pois 
o processo de criação dos endereços de sub-rede é bastante fácil. Além disso, uma vez criadas as 
sub-redes, a memorização dos seus endereços é também muito fácil. Em resumo, podemos citar 
como vantagens do projeto de endereçamento baseado em máscaras de tamanho fixo a simplici- 


dade e a facilidade de criação e memorização dos endereços de sub-rede. 


As duas arquiteturas de endereçamento suportam o projeto de endereçamento baseado em 
máscaras de tamanho fixo. No entanto, vale ressaltar que, na arquitetura classful, a primeira 

e a última sub-rede não podem ser usadas. Essa limitação não existe na arquitetura classless, 
em que todas as sub-redes podem ser utilizadas. 


Por exemplo, considere que o endereço classe C 200.10.16.0 (arquitetura classful) ou o 
bloco de endereço 200.10.16.0/24 (arquitetura class/ess) foi atribuído a uma instituição. 

Se a máscara de 27 bits é adotada, então os seguintes endereços de sub-rede são criados: 
200.10.16.0/27, 200.10.16.32/27, 200.10.16.64/27, 200.10.16.96/27, 200.10.16.128/27, 
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200.10.16.160/27, 200.10.16.192/27 e 200.10.16.224/27. Na arquitetura classless, todos esses 
endereços podem ser atribuídos às sub-redes. No entanto, na arquitetura classful, os 
endereços 200.10.16.0/27 e 200.10.16.224/27 não podem ser usados. 


No projeto de endereçamento baseado em máscaras de tamanho fixo, a máscara adotada é 
determinada pela maior rede física. Portanto, a adoção de máscaras de tamanho fixo impõe 
certo desperdício de endereços, pois as redes físicas menores não usam a maioria dos endereços 
atribuídos a elas. No exemplo citado, cada sub-rede permite até 30 (2º - 2) estações. No entanto, 


se algumas redes físicas possuem apenas 10 estações, cada uma delas desperdiça 20 endereços. 


Para minimizar o desperdício de endereços, a adoção de máscaras de tamanho fixo impõe 
que as redes físicas possuam quantidades semelhantes de estações, reduzindo a flexibili- 
dade para definir a distribuição das estações nas diversas redes físicas. Além disso, con- 
siderando que a máscara limita o número de sub-redes que podem existir, a flexibilidade 
do projeto de endereçamento baseado em máscaras de tamanho fixo torna-se ainda mais 
reduzida. No exemplo citado, a máscara de 27 bits impõe o limite de 6 sub-redes na arquite- 


tura classful e 8 sub-redes na arquitetura classless. 


Em função da baixa flexibilidade, é comum o número de redes físicas ser maior, na prática, do 
que o permitido pela máscara a ser adotada, tornando necessário algum ajuste na estrutura 
de interconexão da inter-rede. Esse ajuste pode ser realizado de duas formas: redução do 
número de redes físicas, para adequar-se ao número de endereços de sub-rede criados; ou 
migração de estações entre redes físicas, para equiparar o número de estações e permitir a 
adoção de uma máscara menor, que gere um número maior de endereços de sub-rede. 


Máscaras de tamanho variável 


a Sub-blocos podem adotar máscaras de tamanhos diferentes (VLSM). 


a Máscaras dependem do número de redes físicas existentes e do número de estações 
em cada rede física. 


a Todos os sub-blocos podem ser atribuídos, incluindo o primeiro e o último. 
o Permite a subdivisão recursiva de blocos. 
o Vantagens 
= Melhor aproveitamento dos endereços. 
m Incremento da flexibilidade da rede. 
a Suporta maior número de sub-redes. 
a Permite um número de estações adequado às finalidades das sub-redes. 
a Arquitetura classful 
m Não suporta VLSM, exceto quando a topologia da inter-rede é hierárquica. 
m Deve respeitar diversas restrições. 
m Requer diversos cuidados de configuração. 
m Amelhor estratégia é não adotar VLSM. 
a Arquitetura classless 
m Suporta VLSM de forma completa e transparente. 


Já conhecemos os principais conceitos e algumas regras associadas ao esquema de ende- 
reçamento de super-redes. No entanto, algumas facilidades adicionais são suportadas pela 
arquitetura classless, tornando mais flexível e eficiente o projeto de alocação de blocos de 
endereços às respectivas redes físicas. 


Figura 4.17 
Subdivisdo do bloco 
200.10.28.0/23. 


Mascara de 
tamanho variavel 


Estratégia de projeto de 
endereçamento cujas 
sub-redes adotam más- 
caras com diferentes 
números de bits nos 
prefixos de sub-rede. 


Embora as duas arquiteturas de endereçamento suportem o conceito de sub-redes, a arqui- 
tetura classless é ainda mais poderosa que a arquitetura classful: 


ao A arquitetura classful restringe o uso da primeira e da última sub-rede criada. Já a arqui- 
tetura classless não impõe essa restrição, permitindo o uso de todos os sub-blocos, que 
serão atribuídos às redes físicas. 


a A arquitetura classful suporta apenas máscaras de tamanho fixo, não permitindo a 
aplicação recursiva do conceito de sub-redes. Por outro lado, na arquitetura classless, 
quando um bloco de endereços é subdividido em sub-blocos, esses sub-blocos podem 
ser novamente subdivididos, gerando sub-blocos de tamanhos diferentes. Como esse 
processo de subdivisão pode ser realizado diversas vezes, a arquitetura classless suporta, 
consequentemente, o uso de máscaras diferentes, permitindo a aplicação recursiva 
do conceito de sub-redes. Por exemplo, o sub-bloco 200.10.28.0/23 da Figura 4.14, que 
possui 512 endereços, pode ser novamente subdividido em 4 blocos de 128 endereços. 


A Figura 4.17 apresenta essa nova subdivisão. 


31 
11001000 00001010 0001110 0 00000000 200.10.28.0/23 
25 31 
11001000 00001010 000111 [00 | 0000000 200.10.28.0/25 


11001000 00001010 000111 0000000 200.10.28.128/25 


11001000 00001010 000111 0000000 200.10.29.0/25 











[o) © 
N 
[=] (e) >] o Ww 


11001000 00001010 000111 0000000 200.10.29.128/25 


Essa flexibilidade é resultado da implementação da função de roteamento da arquitetura 
classless, que não apenas assume que as máscaras dos diversos sub-blocos podem ser dife- 
rentes, mas também dispõe de mecanismos para conhecê-las. Logo, a adoção de máscaras 
diferentes não gera qualquer problema de roteamento. O termo máscaras de tamanho 


variável (Variable-Length Subnet Mask - VLSM) é normalmente usado para indicar a adoção 


de máscaras diferentes. 


Como consequência do uso de máscaras diferentes, os diversos sub-blocos criados podem 
possuir diferentes quantidades de endereços e, portanto, podem comportar diferentes 
números de estações. Assim, o tamanho da máscara a ser usada depende do número de 
redes físicas existentes e do número de estações em cada uma dessas redes. Portanto, 
VLSM é a estratégia de projeto de endereçamento cujas sub-redes adotam máscaras com 
diferentes números de bits nos prefixos de sub-rede. Tal projeto de endereçamento baseado 
em máscaras de tamanho variável minimiza o desperdício de endereços, pois as máscaras 


usadas são apropriadas ao número de estações de cada rede física. 


Por exemplo, uma máscara de 27 bits pode ser atribuída a uma rede física com 25 estações, 
enquanto uma máscara de 29 bits pode ser atribuída a uma rede física com apenas 5 esta- 
ções. Observe que, com máscara de tamanho fixo, a máscara de 27 bits deveria ser adotada 


em ambas as redes físicas, gerando maior desperdício de endereços. 
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Considerando que as máscaras são apropriadas ao número de estações das redes físicas, 
VLSM provê maior flexibilidade ao projeto da estrutura de interconexão física da inter-rede 
e à distribuição das várias estações nessas sub-redes. Portanto, um maior número de redes 
físicas pode ser planejado, cada uma delas com um número de estações adequado às res- 
pectivas finalidades. Em resumo, podemos citar como vantagens do projeto VLSM o melhor 


aproveitamento dos endereços e a maior flexibilidade para a rede. 


A arquitetura classless suporta VLSM de forma completa e transparente, ao contrário da 
arquitetura classful, que não suporta VLSM, exceto quando a estrutura de interconexão da 
inter-rede adota uma topologia hierárquica em que as redes físicas não definem qualquer 
caminho fechado. Mesmo nesse caso, diversas restrições devem ser respeitadas e cui- 
dados adicionais devem ser tomados na configuração dos roteadores. Com base na enorme 
dificuldade de assegurar e administrar tais restrições e cuidados durante o ciclo de vida da 


inter-rede, a melhor estratégia é não adotar VLSM na arquitetura classful. 


Para desencorajar a adoção de VLSM na arquitetura classful, não serão apresen- 
® tados detalhes das restrições que devem ser atendidas e cuidados que devem ser 
tomados. Dessa forma, toda a discussão apresentada a seguir está no contexto da 


arquitetura classless. 


Desvantagens do VLSM 


a Complexo gerenciamento das máscaras. 


o Difícil memorização dos endereços. | 


Apesar das vantagens citadas, VLSM impõe um razoável nível de complexidade para criação 
e gerenciamento das diferentes máscaras, pois qualquer descuido pode gerar blocos de 
endereços sobrepostos. Além disso, VLSM dificulta a memorização das máscaras. 


Portanto, as desvantagens do projeto VLSM são a dificuldade de gerenciamento das máscaras 
e de memorização dos endereços dos blocos. Como essas desvantagens tornam-se mais cri- 
ticas à medida que aumenta o número de máscaras diferentes, cuidados devem ser tomados 
para utilizar um número reduzido de máscaras diferentes e evitar a sobreposição de blocos. 


Algoritmo de atribuição de blocos 


Etapas do algoritmo de atribuição de blocos: 

o Iniciar com o maior bloco requerido. 

o Identificar a máscara que suporta o tamanho do bloco dessa iteração. 

a Subdividir blocos disponíveis em sub-blocos com o tamanho requerido nessa iteração. 
a Alocar os sub-blocos às redes físicas que requerem os blocos dessa iteração. 

a Iniciar nova iteração com o próximo maior bloco requerido. 


O algoritmo de atribuição de blocos permite a adoção do número mínimo de diferentes 
máscaras, evitando a sobreposição de blocos. Para tal, considerando que uma instituição 
possui um determinado bloco de endereços, o algoritmo pressupõe que o número total de 


redes físicas é conhecido, como também o número de estações de cada uma dessas redes. 


Figura 4.18 
Sub-redes e blocos 
de endereços. 


As etapas do algoritmo de alocação de blocos são as seguintes: 


a Encontrar, para cada rede física, o menor tamanho de bloco cujos endereços permitidos 


comportem o número de estações da sub-rede. 


a Determinar o numero de sub-redes para cada tamanho de bloco identificado. 


a Aplicar os passos a seguir, iniciando com os blocos associados às maiores sub-redes e 


concluindo com os blocos associados às menores sub-redes: 


a Identificar a máscara que suporta o tamanho do bloco considerado nesta iteração. 


m Subdividir o bloco disponível (ou sub-blocos, no caso das iterações que não tratam 


os maiores blocos) em sub-blocos cujas máscaras possuem o tamanho considerado 


nesta iteração. 


m Atribuir os primeiros sub-blocos às redes físicas que requerem o tamanho de bloco 


considerado nesta iteração. 


m Iniciar uma nova iteração para o próximo conjunto de blocos de maior tamanho. 


Exemplo VLSM 


Exemplo de bloco de endereço 200.10.16.0/20. 


Sub redes 


1 


10 


Estações 
400 

300 

100 

90 

50 

40 


2 


Tamanho de bloco 
512 

512 

128 

128 

64 

64 


4 


Sub-redes 
2 
6 
7 


10 


Tamanho de bloco 
512 

129 

64 


4 


Suponha uma instituição que possua o bloco 200.10.16.0/20 e as redes físicas indicadas na 


Figura 4.18. Inicialmente, deve-se determinar o tamanho dos blocos requeridos para cada 


rede física. Lembre-se de que o tamanho dos blocos deve ser uma potência de 2. A Figura 


4.18 também mostra os tamanhos dos blocos requeridos para cada rede física. Uma vez 


identificado o tamanho dos blocos, deve-se determinar o número de redes físicas para cada 


tamanho de bloco identificado. Na mesma figura temos essa relação. 


Para seguir o algoritmo, devemos iniciar a atribuição a partir dos maiores blocos e concluir 


com os menores blocos. A Figura 4.19 mostra uma possível subdivisão e atribuição dos 


blocos às diversas redes físicas. 


X Capítulo 4- Endereçamento IP (parte 2) 


133 


Ñ Arquitetura e Protocolos de Rede TCP-IP 


134 


200.10.25.192/30 


200.10.20.0/25 200.10.25.196/30 
200.10.16.0/23 200.10.20.128/25 200.10.25.200/30 
200.10.21.0/25 200.10.25.204/30 
200.10.18.0/23 200.10.21.128/25 200.10.25.208/30 


200.10.25.212/30 
PEA 200.10.25.216/30 
, 10.22. 200.10.25.220/30 
200.10.22:0/23 200.10.22.128/25 200.10.25.224/30 


200.10.25.228/30 


200.10.20.0/23 


200.10.16.0/20 





200.10.24.0/23 


200.10.24.0/26 
200.10.24.64/26 
200.10.24.128/26 
200.10.24.192/26 
200.10.25.0/26 





200.10.25.64/26 Figura 4.19 
200.10.25.128/26 aaee A 
200.10.25.192/26 

(exemplo 2). 


Os blocos de 512 endereços requerem máscaras de 23 bits. Assim, devemos subdividir o 
bloco 200.10.16.0/20, que possui 4.096 (21?) endereços, em sub-blocos de 23 bits. Observe 
que estamos deslocando 3 bits da máscara, gerando, assim, 8 (2º) sub-blocos de 512 (2º) 
endereços. Os sub-blocos 200.10.16.0/23 e 200.10.18.0/23 são atribuídos às duas redes do 
exemplo que demandam blocos de 512 endereços. 


Os blocos de 128 endereços adotam máscaras de 25 bits. Subdividindo um bloco de 512 
endereços, que possui 23 bits na máscara, em sub-blocos de 128 endereços, deslocamos 
2 bits da máscara e obtemos 4 (2?) sub-blocos. Portanto, para atribuir 6 blocos de 128 
endereços, devemos subdividir 2 blocos de 512 endereços. Nessa subdivisão, obtemos 

8 blocos de 128 endereços. 


A Figura 4.19 mostra a subdivisão dos blocos 200.10.20.0/23 e 200.10.22.0/23 em sub-blocos 
de 25 bits. Os sub-blocos 200.10.20.0/25, 200.10.20.128/25, 200.10.21.0/25, 200.10.21.128/25, 
200.10.22.0/25 e 200.10.22.128/25 são atribuídos para as seis sub-redes do exemplo que 


demandam blocos de 128 endereços. 


Os blocos de 64 endereços usam máscaras de 26 bits. Subdividindo um bloco de 512 ende- 
reços, que possui 23 bits na máscara, em sub-blocos de 64 endereços, deslocamos 3 bits 
da máscara e obtemos 8 (23) sub-blocos de 64 endereços. Logo, para atribuir 7 blocos de 
64 endereços, devemos subdividir um bloco de 512 endereços. A Figura 4.19 mostra a sub- 
divisão do bloco 200.10.24.0/23 em sub-blocos de 26 bits. Os sub-blocos 200.10.24.0/26, 
200.10.24.64/26, 200.10.24.128/26, 200.10.24.192/26, 200.10.25.0/26, 200.10.25.64/26 e 
200.10.25.128/26 são atribuídos para as 7 sub-redes do exemplo, que demandam blocos 
de 64 endereços. 


Vale ressaltar que os blocos 200.10.23.0/25 e 200.10.23.128/25, que possuem 128 endereços, 
estão livres e poderiam ser subdivididos para gerar 4 blocos de 64 endereços. Observe que 
cada bloco de 128 endereços pode ser subdividido em dois blocos de 64 endereços. No 
entanto, a subdivisão destes blocos de 128 endereços ainda não seria suficiente para criar 
os 7 blocos requeridos. Assim, é preferível mantê-los livres, reservando espaço para possí- 


veis redes físicas de 128 endereços que venham a existir no futuro. 


Por fim, os blocos de 4 endereços adotam máscaras de 30 bits. Subdividindo um bloco 
de 64 endereços, que possui 26 bits na máscara, em sub-blocos de 4 endereços, deslo- 
camos 4 bits da máscara e obtemos 16 (2º) sub-blocos de 4 endereços. Portanto, para 


atribuir 10 blocos de 4 endereços, conforme mostra a Figura 4.19, devemos subdividir 


o bloco 200.10.25.192/26 em sub-blocos de 30 bits. Os sub-blocos 200.10.25.192/30, 
200.10.25.196/30, 200.10.25.200/30, 200.10.25.204/30, 200.10.25.208/26, 200.10.25.212/30, 
200.10.25.216/30, 200.10.25.220/30, 200.10.25.224/30 e 200.10.25.228/30 são atribuídos 


para as dez sub-redes do exemplo, que demandam blocos de quatro endereços. 


Note que o método BOX não pode ser aplicado neste exemplo, pois nele são divididos 
blocos que ultrapassam o limite de um octeto. 


® 
Exercício de fixação iG 
Mascara de tamanho variável 


Considere o bloco 192.168.10.0/24, com divisão em 3 sub-redes. Tamanho das redes físicas: 
o Uma rede com 120 máquinas. 


a Duas redes com 60 máquinas cada. 


Para calcular as sub-redes e as máscaras, é necessário ter um melhor entendimento do 
algoritmo. Para isso vamos desenvolver um exemplo de atribuição de blocos. Neste exemplo 
de máscara de tamanho variável (VLSM), vamos calcular as sub-redes de acordo com as 
premissas a seguir: 


a Dividir o bloco 192.168.10.0/24 em 3 sub-redes; 
a Tamanho das redes físicas: uma rede com 120 máquinas e duas redes com 60 máquinas cada. 


Usando o algoritmo de atribuição de blocos, teremos as etapas: 


1. Qual o maior bloco requerido? endereços para a rede com 120 máquinas. 
2. Qual será a máscara desse bloco? . 
3. Como ficaria a primeira sub-rede? — 


4. Como ficaria a segunda sub-rede? — __; esta sub-rede 


deve ser dividida novamente para comportar as duas redes físicas que restam. 
5. Qualo próximo maior bloco para suportar 60 máquinas? endereços. 
6. Qual será a máscara desse bloco? . 


7. Como serão estas sub-redes? 





8. Como ficarão as sub-redes com a aplicação do método BOX? 














Contiguidade de sub-redes 


am 
Sub-redes podem adotar qualquer estrutura de interconexão, com ou sem contiguidade. 


Sub-redes contíguas são um projeto de endereçamento no qual todas as sub-redes 
oriundas de um mesmo endereço de rede (classe A, B ou C) devem se comunicar, sem 


que os datagramas atravessem redes físicas com outro endereço de rede. 


Na arquitetura classful as diversas sub-redes físicas devem ser contíguas, não podendo 
existir porções isoladas. Já na arquitetura classless, as diversas sub-redes (sub-blocos) 
podem adotar qualquer estrutura de interconexão, com ou sem contiguidade, podendo se 
comunicar através de redes físicas que pertencem a outros blocos de endereços. 
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Por exemplo, a Figura 4.20 mostra uma atribuição válida na arquitetura classless, em que as 
redes N1, N2, N3 e N4, todas oriundas do bloco 200.10.16.0/20, são separadas pela rede N5, 
que não pertence ao bloco 200.10.16.0/20. 


200.10.16.0/23 200.10.18.0/23 


+ 150.20.1.0/27 Da Figura 4.20 
Exemplo de 
contiguidade de 


200.10.28.0/25 200.10.28.128/25 sub-redes. 


Observe que as redes N1 e N3 adotam máscaras diferentes daquelas das redes N2 e N4. 


Agregação de rotas 


a Roteadores externos conhecem apenas a rota para o bloco agregado. 


o Reduz tamanho da tabela de roteamento. | 


Agregação de rotas é o processo que reduz o tamanho das tabelas de roteamento através 
da exploração do conceito de agregação de blocos. Neste processo, as rotas para cada 
sub-bloco individual são representadas por uma única rota que aponta para o endereço do 
bloco agregado. Generalizando, o processo de agregação de rotas é aquele em que rote- 
adores externos (qualquer roteador não conectado às redes para as quais os sub-blocos 
estão atribuídos) não precisam conhecer rotas para cada sub-bloco individual, mas apenas 
para o endereço do bloco agregado. 


Portanto, a arquitetura classless explora o conceito de agregação de blocos para reduzir o 


tamanho das tabelas de roteamento, Por exemplo, na Figura 4.21, o roteador R2 conhece... Tabela de roteamento, 

apenas a rota via R1 para o bloco agregado 200.10.28.0/23, ao invés de uma rota particular Estrutura de dados 

para cada um dos seus sub-blocos (200.10.28.0/25, 200.10.28.128/25, 200.10.29.0/25 e mantida por todas as 
estações e roteadores 

200.10.29.128/25), atribuídos às redes N1, N2, N3 e N4. O fato do bloco 200.10.28.0/23 ser de uma inter-rede. A 

subdividido em sub-blocos é transparente para o roteador R2. tabela de roteamento 


contém informações 
sobre as rotas para 
alcançar as possíveis 
redes ou estações de 
uma inter-rede. 


Figura 4.21 


Exemplo de agre- 
gação de rotas. 


Figura 4.22 
Faixas de endereços 
privados. 


200.10.28.128/25 200.10.29.0/25 


R1 


200.10.29.128/25 





200.10.28.0/25 


200.10.16.0/23 


Arquiteturas classful e classless 


Arquitetura classful: 

o Proíbe a atribuição da primeira e da última sub-rede. 
a Maior desperdício de endereços. 

a Menor flexibilidade no projeto da rede. 

Arquitetura classless: 

o Permite o uso de todas as sub-redes. 

a Menor desperdício de endereços. 


a Maior flexibilidade no projeto da rede. 





Podemos citar como desvantagens do projeto de endereçamento baseado em máscaras de 
tamanho fixo o desperdício de endereços e a redução da flexibilidade da rede. Observe que 
essas desvantagens são mais críticas na arquitetura classful, pois a primeira e a última sub-rede 
não podem ser usadas, o que aumenta ainda mais o desperdício de endereços e reduz a flexibi- 
lidade do projeto. 


Endereços privados 


Conjuntos de endereços reservados que podem ser usados livremente por qualquer a 
organização. | 
Classe Endereços privados 
A 10.0.0.0 - 10.255.255.255 
B 172.16.0.0 - 172.31.255.255 


: 192.168.0.0 - 192.168.255.255 
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O crescimento exponencial da internet requer mecanismos que permitam aproveitar 
melhor o espaço de endereçamento global, para assim evitar a indisponibilidade de 
endereços em um futuro próximo. Nesse sentido, o conceito de endereço privado foi 
introduzido, provendo um conjunto de endereços reservados que podem ser usados 
livremente por qualquer organização, sem autorização prévia. 


Essas faixas de endereços estão representadas na Figura 4.22. Observe que um único endereço 
de rede classe A é reservado. No entanto, para as classes B e C, o número é bem maior, sendo 


reservados 16 endereços de rede classe B e 256 endereços de rede classe C. Ver RFC 1918. 


Endereços públicos x privados 


Endereços públicos: 

a Atribuidos oficialmente a uma organização por uma instituição autorizada da internet. 
a Possuem unicidade global. 

o Devem ser solicitados por organizações que desejam conectar-se à internet. 
Endereços privados: 

a Não são oficialmente atribuídos por instituições autorizadas da internet. 


a Possuem unicidade local, sendo únicos apenas na inter-rede privada. 
Podemos dizer que o espaço de endereços IPv4 é dividido em dois: 


o Endereços públicos - possuem unicidade global e somente podem ser atribuídos para uma 
organização por uma instituição autorizada da internet. Assim, qualquer organização que 


necessite acessar a internet deve obter endereços públicos de uma instituição autorizada. 


o Endereços privados - podem ser usados livremente por qualquer organização porque 
não são oficialmente atribuídos por instituições autorizadas da internet. Possuem apenas 
unicidade local, ou seja, são únicos apenas na inter-rede privada, mas não identificam de 


forma única as estações na internet. 


Como endereços privados não possuem unicidade global, as diversas estações e redes pri- 
vadas não devem ser visíveis externamente na internet. Logo, informações de roteamento 
sobre redes privadas não podem ser propagadas na internet. Além disso, datagramas IPv4 
com endereços privados trafegam apenas internamente e não devem, portanto, ser rote- 
ados para fora da inter-rede privada. 


Endereços privados - motivação 


no Escassez de endereços IPv4 disponíveis. 
a Mudanças de provedor de internet (ISP). 
a RFC 1918 - endereços privados 
m 10.0.0.0 a 110.255.255.255 (10/8) 
a 172.16.0.0 a 172.31.255.255 (172.16/12) 
m 192.168.0.0 a 192.168.255.255 (192.168/16) 


a Segurança 


Figura 4.23 
Notação CIDR para 
endereços privados. 


NAT 


Técnica de reescrever 
endereços IPv4 nos 
cabeçalhos e dados das 
aplicações, conforme 
política definida, 
baseada no endereço 
IPv4 de origem e/ou 
destino dos pacotes 
que trafegam pelos 
equipamentos que 
implementam NAT. 


Classe RFC 1918 CIDR 


A Í 10.0.0.0 - 10.255.255.255  10.0.0.0/8 
B o o DIDO [723] 255255 É 172.16.0.0/12 
É 192.168.0.0 - 192.168.255.255 É 192.168.0.0/16 


a 172.16.0.0 - 172.31.255.255: 172.16.0.0/12 
m De onde vem 0/12? 
a 12 bits em comum que definem a rede 


10101100 . 0001p000 . 00000000 . 00000000 - 172.16.0.0 
10101100 . 000171111 . 11111111 . 11111111 - 172.31.255.255 


10101100 . 00010000 . 00000000 . 00000000 - 172.16.0.0/12 





A faixa de endereços 172.16.0.0/12 é composta de um bloco de 16 redes Classe B, cujos 
endereços de redes são: 172.16.0.0/16, 172.17.0.0/16, 172.18.0.0/16, até 172.31.0.0/16, porque 
o prefixo de rede original deste bloco é /12, que significa o primeiro octeto e os primeiros 

4 bits do segundo octeto. Variando os últimos 4 bits do segundo octeto de “0000” até “1111” 


obtemos os valores decimais de 16 até 31 no segundo octeto. 
Benefícios: 

a Otimiza o uso do espaço de endereços IPv4. 

a Provê um mecanismo de segurança. 

Limitações: 

o Estações e redes privadas não podem ser visíveis externamente na internet. 


a Datagramas com endereços privados trafegam apenas na inter-rede privada. 


Solução: 





a Network Address Translation (NAT) 


Estações privadas podem se comunicar com outras estações (públicas ou privadas) dentro 
da inter-rede privada, mas não possuem conectividade IP com qualquer estação fora da 
inter-rede privada. Embora não possuam conectividade direta, estações privadas podem 
acessar serviços externos por meio de tradutores de endereços, comumente implemen- 
tados por soluções Network Address Translation (NAT). 


A vantagem da adoção de endereços privados para a internet é conservar o espaço de 
endereçamento global, não atribuindo endereços públicos onde a unicidade global não é 
requerida, ou atribuindo blocos relativamente pequenos de endereços públicos onde a 
unicidade global pode ser contornada com o uso de soluções NAT. Além disso, como 
estações e redes privadas não são visíveis externamente na internet, endereços privados 
também são adotados como mecanismo de segurança. 
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Exemplo NAT 


Interno Externo Interno Externo 










Internet Internet 


128.23.2.2 


Endereço local interno Endereço global interno 


10.0.0.3 179.9.8.80 
DA SA DA SA 
Cabeçalho IP Cabeçalho IP 
Neste exemplo, o endereço privado 10.0.0.3 é traduzido pelo roteador NAT (RTA) para o Figura 4.24 
endereço público 179.9.8.80, quando o pacote é enviado para a internet. Na volta, o pro- eae NAT 
parte 1). 


cesso inverso é realizado no mesmo ponto. 


Interno Externo Interno Externo 






Internet Internet 


128.23.2.2 





179.9.8.80 








NAT Table 


Inside Local IP Adress Inside Global IP Adres : 





10.0.0.3 à 179.9.8.80 
DA SA DA SA 
10003 | rza2322|.. | ome J] r7s9a80 [82022] . | owe | 
Cabeçalho IP Cabecalho IP 


Figura 4.25 Na volta, o processo NAT realiza a tradução de um endereço IPv4 de destino público para 
Exemplo NAT 


Pae um endereço IPv4 de destino privado. No exemplo acima, o endereço público 179.9.8.80 é 
parte 2). 


traduzido para o endereço privado 10.0.0.3. NAT permite que você tenha mais endereços 
IPv4 do que os que você tem atribuídos, usando o espaço de endereçamento do RFC 1918, 
mesmo com uma máscara restrita. 


Entretanto, pela necessidade de usar os endereços IPv4 públicos para a internet, NAT limita 
o número de hosts acessando a internet simultaneamente, dependendo do número de 


hosts permitido pela sua máscara dos endereços IPv4 públicos. 
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Tipos de NAT 


mn Estático - associa um endereço privado a um endereço público em uma relação “um para 


um”. Particularmente útil no caso de serviços internos serem acessíveis externamente. 


o Dinâmico - associa um grupo de endereços privados a um grupo de endereços 
públicos em uma relação “muitos para muitos”. 


ao Sobrecarga (Overloading) - uma forma de associação de múltiplos endereços IP 
internos a um único endereço externo usando diferentes portas TCP/UDP. Também 
conhecido como Port Address Translation (PAT), NAT de endereço único ou NAT multi- 


plexado em portas. 


o Sobreposição (Overlapping) - quando os endereços IP usados na sua rede interna 
também são usados na rede externa, o roteador deve manter uma tabela destes 
endereços para que consiga interceptá-los e trocá-los por endereços IP públicos 
únicos em ambas as direções. Vale salientar que o roteador NAT deve traduzir os 
endereços privados para endereços públicos, assim como traduzir os endereços 
públicos para endereços que sejam únicos dentro da rede. Isto pode ser feito através 


do NAT estático ou usando DNS com NAT dinâmico. 


Este último caso somente ocorre quando é necessário interconectar duas redes privadas 
com endereços que se superpõem. Exemplo: suponha que o mesmo órgão público utilize 
num prédio a rede privada 172.16.0.0/16, e em outro prédio a mesma faixa de endereços 


para outra rede física (os dois prédios não estão interligados). 
Se for necessário interligar as duas redes físicas dos dois prédios, duas alternativas são possíveis: 


1. Redefinir os endereços privados de uma das redes para evitar a sobreposição; 


2. Usar o esquema de NAT Overlapping, que não exige a mudança de endereços de 


nenhuma das duas redes físicas. 


NAT Estático 


CJ 
o Tradução estática (um para um) na qual um mapeamento é especificamente configu- 


rado numa tabela. 


a Um Inside Local Address específico é mapeado para um Inside Global Address específico. 


NAT Table 
Inside Local IP Adress Inside Global IP Adress 


10.1.1.7 à 171.70.2.10 


fe Internet 


EO 10.1.1.1 cee G 
Az 171.70.1.1 


NAT Router 








Web Server 
10.1.1.7 


Figura 4.26 
NAT Estático. 


No exemplo da Figura 4.26, o endereço local 10.1.1.7 é mapeado para o endereço global 
171.70.2.10. 


Comandos de configuração de NAT Estático 
o Passo 1: define o mapeamento estático 


Router(config)#ip nat inside source static Jocal-ip global-ip 
ao Passo 2: especifica a interface interna 

Router(config)#interface type number 

Router(config-if)#ip nat inside 

o Passo 3: especifica a interface externa 


Router(config)#interface type number 

















Router(config-if)#ip nat outside 
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192.168.1.2 









hostname GW 
! 
ip nat inside source static 10.1.1.2 192.168.1.2 
! 
interface ethernet 0 
ip address 10.1.1.1 255.255.255.0 
ip nat inside 








interface serial 0 
ip address 192.168.1.1 255.255.255.0 
ip nat outside 


Figura 4.27 
Exemplo de con- 
figuração de NAT 








Estático. 
NAT Dinâmico 
a Associação dinâmica dos IPs privados a endereços públicos disponíveis de um 
conjunto definido. 
a Relação “muitos para muitos”. 
RTA 
EO 10.1.1.1 ar Gales 
> Ae 171.70.1.1 
NAT Router 
Web Server Figura 4.28 
10.1.1.7 NAT Dinâmico. 


Figura 4.29 
Tabela NAT: 
exemplo da 
Figura 4.28. 


IP Local Interno IP Global Interno 


10.1.1.0/24 200.143.190.1-254 


O NAT dinamico funciona assim: 
a Uma rede interna foi configurada com endereços IPv4 privados (RFC 1918) e não roteaveis, 
já que não são únicos, como por exemplo, a rede 10.1.1.0/24 mostrada na tabela NAT; 


a O roteador compatível com o NAT é configurado com a faixa de endereços IPv4 públicos 


da empresa, como por exemplo a rede 200.143.190.0/24 mostrada na tabela NAT; 


a Um computador da rede interna tenta se conectar a um computador da rede externa, 


como, por exemplo, um servidor de internet; 
a O roteador recebe o pacote do computador da rede interna; 


a O roteador salva o endereço IPv4 privado não roteável do computador em uma tabela de 
tradução de endereços. O roteador substitui o endereço IPv4 privado não roteável do com- 
putador de origem pelo primeiro endereço IPv4 público disponível na faixa de endereços IP 
exclusivos. A tabela de tradução agora tem um mapeamento do endereço IPv4 privado não 
roteável do computador, correspondente a um dos endereços IPv4 públicos exclusivos; 


o Quando um pacote volta do computador de destino, o roteador confere o endereço de 
destino no pacote. Ele então busca na tabela de tradução de endereços o computador 
da rede interna ao qual o pacote pertence. Ele muda o endereço de destino para um dos 
endereços salvos na tabela de tradução, e envia o pacote para aquele computador. Se ele 


não encontrar um correspondente na tabela, descartará o pacote; 


a O computador recebe o pacote do roteador. O processo se repete enquanto o compu- 
tador estiver se comunicando com o sistema externo; 


oa O mesmo processo será realizado para todos os computadores da rede interna. 


Configurando NAT Dinâmico 
a Passo 1: criar um pool de endereços globais 
Router(config)#ip nat pool name start-ip end-ip 


{netmask netmask | prefix-length prefix-length} 
a Passo 2: criar uma Access Control List (ACL) para identificar hosts para tradução 


Router(config)#access-list access-list-number permit source [source- 
wildcard] 


ao Passo 3: configurar NAT Dinâmico baseado no endereço de origem 


Router(config)#ip nat inside source list access-list-number pool 
name 


ao Passo 4: especificar uma interface interna 
Router(config-if)#ip nat inside 
o Passo 5: especificar uma interface externa 
Router(config-if)#ip nat outside 
Em um roteador Cisco, as entradas na tabela NAT dinâmicas são armazenadas, por default, 


por 24 horas. Assim que o prazo de validade das entradas expirar, hosts externos não serão 


mais capazes de acessar os hosts internos, até que uma nova entrada seja criada na tabela. 
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A entrada na tabela só pode ser criada a partir da rede interna. Um timeout de 24 horas é 


relativamente longo. Para ajustar o tempo máximo de tradução, use o seguinte comando: 
Router(config)#ip nat translation timeout seconds 


Embora NAT não seja um firewall seguro, pode prevenir que intrusos iniciem conexões com 
os hosts internos. NAT tem o efeito de esconder a estrutura interna da rede, evitando que os 


usuários externos possam ver os endereços dos hosts internos. 


10.1.1.2 O endereço IP do Tabela de roteamento: 
provedor é 179.9.8.0/24 179.9.8.0/24 via 192.168.1.1 






192.168.1.1 


EEE Traduz para estes 
10.1.0.2 endereços externos 
ip nat pool nat-pooll 179.9.8.80 179.9.8.95 netmask 255.255.255.0 
Início ip nat inside source list 1 pool nat-pooll 
1 


interface ethernet 0 
ip address 10.1.1.1 255.255.0.0 
ip nat inside 


1 
interface serial 0 





ip address 192.168.1.1 255.255.255.0 Endereço IP de origem Figura 4.30 

ip nat outside ERR A . 
ri el a deve coincidir aqui Exemplo de NAT 
access-list 1 permit 10,1.0.0 0.0.255.255 Dinamico. 


Neste exemplo, a rede interna 10.1.0.0/16 é mapeada nos endereços externos de 179.9.8.80 
a 179.9.8.95. O último comando define uma lista de acesso de número 1. Nesse comando é 
usado um “wild card”, que é o complemento para 255 da máscara de sub-rede. O octeto com 
valor zero obriga que o valor seja exatamente igual ao do endereço IP. O octeto com valor 


255 permite qualquer valor de endereço. 


No exemplo acima, os endereços IP permitidos são todos com valores de 10.1.0.0 a 


10.1.255.255. Os dois primeiros octetos têm que ser 10.1 e os dois últimos podem ter qual- 


quer valor. 
a 
é PAT 
$ 
a a Com Port Address Translation (PAT), vários endereços IP privados podem ser tradu- 
oO 
a zidos para um unico endereco publico (muitos para um). 
E a Também denominado NAT overload. 
o 
a ao Resolve a limitação do NAT Estático, que era “um para um”. 
oO 
E 
> 
E 
5 
g 
xt 
M 
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Interno Externo 





128.23.2.2 






SA “DA 
10.0.0.3:1444 | 128.23.2.2:80 





SA “DA 
10.0.0.2:1331 | 128.23.2.2:80 


202.6.3.2 


Figura 4.31 


Conceito de PAT. 10.0.0.2 


a Permite o uso de um único endereço IPv4 público e define-o para até 65.535 hosts 
internos (4 mil é um número mais realista); 


a Modifica a porta de origem TCP/UDP para rastrear endereços de hosts internos; 


a Rastreia e traduz SA (Source Address - Endereço de origem), DA (Destination Address - 
Endereço de destino) e SP (Source Port - Porta TCP ou UDP de origem), que definem de 
maneira única cada conexão, para cada fluxo de tráfego; 


ao NAT overload funcionará desde que os números das portas globais internas sejam únicos 
para cada host local interno; 


a Por exemplo, se os hosts em 10.1.1.5 e 10.1.1.6 usarem ambos a porta TCP 1234, o 
roteador NAT pode criar entradas estendidas na tabela, mapeando 10.1.1.5:1234 para 
171.70.2.2:1234 e 10.1.1.6:1234 para 171.70.2.2:1235; 


ao Defato, implementações de NAT não tentam necessariamente preservar o número de 


porta original. 


No exemplo a seguir, os pacotes estão indo no sentido de Inside para Outside. 
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Interno Externo 


X 





00000 





= A 128.23.2.2 


10.0.0.3 


te 


Tabela NAT/PAT 


mantém tradução 

de: DA, SA, SP LOO 
SS 
— A 





SA 
—> 179.9.8.80 | 202. 









80 1331 2 so 3333 Data 
TCP/UDP 


Header 


IP Header TCP/UDP IP Heade 


Header 


SA “DA DP SP SA DA 
282332 80 (1555 Data —> 179.9.8.80 1282322 so] 2222 Data 





10002 
IP Header TCP/UDP IP Header TCP/UDP 
Header Header 
Figura 4.32 
Exemplo de PAT 
(parte 1). 


Interno Externo 





128.23.2.2 





| Tabela NAT/PAT mantém 
R tradução de: SA (DA), DA LS 
EE Ss 
(SA), DP (SP) = A 


E g 


10.0.0.2 


oo000 





DA SA DP SP. DA “SA “DP sp 
10.003 202632 | 1331 80 Data €— 1799880 202632 3333 80 Data 
= IP Header TCP/UDP IP Header TCP/UDP 


Header Header 
DA _SA DP SP DA SA DP SP 


10.0.0.2 1282332 1555 80 Data “— 1799880 1282322 2222 80 Data 


IP Header TCP/UDP IP Header TCP/UDP 
Header Header 


Figura 4.33 No exemplo acima, os pacotes estão indo no sentido de Outside para Inside. A tabela NAT é a 


Exemplo de PAT mesma, mas agora 0 processo é inverso. 


(parte 2). 
Configurando PAT 
Neste exemplo, um único endereço IPv4 público é utilizado, usando PAT e portas de 
origem para diferenciação entre os diversos fluxos de tráfego. | 
Router(config)#access-list 1 permit 10.0.0.0 0.0.255.255 
Router(config)#ip nat pool nat-pool2 179.9.8.80 netmask 255.255.255.240 
Figura 4.34 
Configurando PAT Router(config)# ip nat inside source list 1 pool nat-pool2 overload 
(parte 1). 


Estabelece a tradução sobrecarga e especifica o endereço IP que será usado, conforme 
especificado no pool. 
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= o : 


192.168.3.7 E0:192.168.3.1 


ta $0:172.16.2.1 ao 


= psdb das E1:192.168.2.1 





192.168.2.4 


interface ethernet 0 
ip address 192.168.3.1 255.255.255.0 
ip nat inside 

! 

interface ethernet 1 
ip address 192.168.2.1 255.255.255.0 
ip nat inside 

1 


interface serial 0 
ip address 172.16.2.1 255.255.255.0 
ip nat outside 

! 


P nat inside source list 1 interface serial 0 overload i 
Figura 4.35 


Configurando PAT 
(parte 2). 





Verificando traduções NAT 
RTX# show ip nat translations verbose 
Pro Inside global Inside local Outside local Outside global 
icmp 420.0, 5521536 I92.1683.0.21cIS36 10.0.0.5:1536 10,0, 521536 
create 00:00:09, use 00:00:06. left 00:0053; 
flags: 


extended, use_count: 0 


Router # show ip nat translations 
Pro Inside global Inside local Outside local Outside global 
coo 192,168,2- lows HO iOS 172- M52 2223 172, 0,2 es 


tep 192168-211067 101.11057 ORS 172 E2382 


SanJosel# show ip nat statistics 
Total active translations: 3 (3 static, O dynamic, O extended) 


Outside interfaces: 


Figura 4.36 
Verificando 
traduções NAT. 


Figura 4.37 
Depuração (debug) 
em traduções NAT. 


Serial0/0 

Inside interfaces: 
FastEthernet0/0 

Hits: 4 misses: 0 
Expired translations: 0 
Dynamic mappings: 


A palavra-chave “verbose” pode ser usada com este comando para mostrar mais informa- 


ções, incluindo o tempo restante para uma entrada dinâmica. 
Resolução de problemas em traduções NAT 
Router# debug ip nat 


ATS SO o 1=2192, M6821, 0=172:16-2;2 LOI 
AEDES 0/2006 2a DO ZA SR O i. (LO 


Me SAO A SAO 0/2 MG .2.2 LL] 


Als SOL LIS 68.2.1, 0/22 [2] 
Me SO Lollo L=AISZ, VOZ GHl/2NG.2.2 (31 
Als 55172.1622; 0192:1068, 2 1-710111 FL] 


Als S=il72. 16:2-2; 05192.1682 l-10 ial (Lid 
ATES OTT ocena rA] 
Als SO lol 1-2192. OZ, 05172.1622 L51 
Als SO AL IS OZ, 0172.10.22 I6] 
Me S72 NGc2.2, 05192.1682: 110.111 EZ] 


























Os pacotes restantes trafegarão pelo caminho rápido se existir uma entrada no cache. 
oa Séo endereço de origem; 
o a.b.c.d -> w.x.y.z é o endereço que foi traduzido; 


o déo endereço de destino. 


O valor entre colchetes é o número de identificação IP. Esta informação pode ser útil para 
debug, pois permite comparar os dados do debug com os dados de outras fontes, tal como 


pacotes de trace originados por sniffers. 


Limpando traduções NAT 


Uma vez que NAT é habilitado, nenhuma mudança pode ser feita no seu processo 
enquanto traduções dinâmicas estiverem ativas. 
Use o comando clear ip nat translation * para limpar a tabela NAT. 


router# show ip nat translations 


Pro Inside global Inside local Outside local Outside 
global 


Cep IMZ DZ OS MO MOS 172-10 22623 NZ So «2823 
ECO LS Moe. 2 UNO! lO Melo” 172-1623323 72 M.A 028 


router 
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router# clear ip nat trans * 
router# show ip nat trans 
Figura 4.38 


router# <nothing> Limpando 
traduções NAT. 


Tendo sido habilitada a tradução NAT num roteador ou servidor, enquanto traduções 
dinâmicas estiverem ativas, nenhuma modificação pode ser feita, sob pena de perder 
sessões TCP/UDP em andamento e, por conseguinte, prejudicar as aplicações que estão 


usando as traduções NAT. 
Não existindo traduções ativas, a tabela NAT pode ser limpa através do comando: 
clear ip nat translation * 


NAT Overlaping não será tratado neste curso porque envolve uma situação particular, na qual 
duas redes privadas usando a mesma faixa de endereços devem ser interligadas, e o adminis- 


trador da rede optou por não refazer o esquema de endereçamento em um primeiro momento. 


Endereços IPv6 














Objetivo: 
a Identificar, de forma única e individual, cada dispositivo da inter-rede TCP/IP. 
o Inicialmente denominado IPng (Next Generation). 
Representação: 
a 8 grupos de 16 bits = 128 bits. 
o Permite até 2! endereços. 
Os 32 bits dos endereços IPv4 são divididos em quatro grupos de 8 bits 
cada, separados por ".”, escritos com dígitos decimais. 
192.168.10.1 
A representação dos endereços IPv6, divide o endereço em oito grupos Fi 
z er A Pd é Ei igura 4.39 
de 16 bits, separando-os por “:”, escritos com dígitos hexadecimais. J 
IPv6 Representação 
de endereços 
2001:0DB8:AD1F:25E2:DFA1:F0C4:5311:84C1 SRA 
Vamos discutir inicialmente o porquê de um novo esquema de endereçamento. 
a Arquitetura classful x classless. 
Figura 4.40 
a Administração endereços IPv4 IANA. Registros regionais 
or bert ee da internet. 
a Ultimos 5 blocos /8 distribuídos em 03/02/2011. Fonte: IANA. 
Re Registry Area Covered 
= AfiNIC Africa Region 
a APNIC Asia/Pacific Region 
i - ARIN North America Region 
oe) LACNIC Latin America and some Caribbean Islands 
- + 


RIPE NCC Europe, the Middle East, and Central Asia 


A situação da distri- 
buição atualizada 
desses blocos pode ser 
vista digitando 
“Contador do Esgota- 
mento do IPv4” em sua 
ferramenta de busca. 
Por ele pode-se 
verificar que o RIR 

APNIC já não tem mais 
endereços para 
distribuir desde 
15/04/2011. Idem para 
o IANA, uma vez que 
todos os blocos IPv4 já 
foram distribuídos para 
os 5 RIR desde 
03/02/2011. Os demais 
RIR têm seu esgota- 
mento de endereços 
IPv4 previsto para os 
próximos anos. 




















Vimos que a arquitetura classful, originalmente concebida, teve de ser abandonada por 
causa do crescimento da internet e da própria estrutura de classes que se mostrou inefi- 
ciente na atribuição de endereços para as diferentes redes físicas. Em função da necessi- 
dade de evitar o desperdício de endereços IPv4 e seu rápido esgotamento, foi amplamente 
adotada a arquitetura classless. Mas essa solução apenas adia o inevitável, uma vez que o 
crescimento desordenado da internet exigia cada vez mais quantidades maiores de ende- 


reços IPv4, muito acima da capacidade de endereçamento do IPv4 com apenas 32 bits. 


Para se ter uma ideia do problema de esgotamento de endereços IP, vamos dar um pano- 
rama da situação atual da atribuição de endereços IPv4. O órgão encarregado de atribuir 
endereços IPv4 é o Internet Assigned Numbers Authority (IANA) - Autoridade de Atribuição 
de Números na Internet, que delega essa atribuição para 5 grandes Regional Internet 
Registry (RIR)- Registro Regional da Internet, conforme mostra a Figura 4.40. 


No Brasil, estamos situados na área do LACNIC. Cada RIR possui certa quantidade de blocos 
/8 (16 milhões de endereços) para distribuir aos países da sua área de atuação. O RIR dis- 
tribui os blocos de acordo com a demanda. Em geral, são distribuídos pedaços dos blocos de 


endereços (sub-blocos) de acordo com a necessidade devidamente justificada pelo usuário. 


Prevendo a escassez de endereços IPv4, a Microsoft comprou um bloco de endereços da 
Nortel (digite em seu buscador “Microsoft foge da implantação do IPv6”). Esta notícia pre- 


nuncia a existência de um “mercado negro” de endereços IPv4. 


Formato do endereço IPv6 


Os endereços IPv6 são divididos em grupos de 16 bits separados por “:” (diferente do IPv4, 
em que os octetos são separados por “.”) e representados em hexadecimal (decimal no 
caso do IPv4). A hierarquia é a mesma do endereço IPv4: prefixo de rede e identificador de 
estação. Não existem classes de endereços com restrição de quantidade de octetos para 


rede e estação. 


A máscara de rede/sub-rede é sempre representada no formato de contagem de bits. 


Distribuição de endereços IPv6 


È 


Blocos IPv6 são distribuídos de forma hierárquica: 

o Cada RIR recebe da IANA um bloco /12. 

o Os provedores recebem dos RIRs blocos /32. 

a Os clientes dos provedores recebem blocos /48 ou /56. 


o Cliente doméstico recebe bloco /64 (apenas 1 rede). 
A distribuição de blocos IPv6 é feita de forma hierárquica: 


o Cada RIR recebe da IANA um bloco /12; 
o Os provedores recebem dos RIRs blocos /32; 
a Os clientes dos provedores devem receber blocos /48 ou /56, dependendo das 


suas necessidades. 


Um cliente só deve receber um bloco /64 se tiver certeza de que apenas uma rede atende 
as suas necessidades (exemplo: usuários domésticos). Isto significa que não devem existir 


sub-redes IPv6 com prefixos de rede maiores que /64. 
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Os provedores devem entregar aos seus clientes blocos variando entre /48 e /56, dependendo 
de suas necessidades: 
o Um bloco /48 pode ser dividido em até 65.536 sub-redes diferentes; 


a Um bloco /56 pode ser dividido em até 256 sub-redes diferentes. 


Implantação do IPv6 


No âmbito acadêmico, existem diversos grupos de pesquisa que trabalham no desenvolvi- 
mento de projetos relacionados ao protocolo IPv6, destacando-se os projetos: 

a Rede CLARA (Cooperação Latino-Americana de Redes Avançadas); 

a GÉANT2; 

o Internet2; 

o KAME; 

a USAGI (Universal playground for IPv6). 

No Brasil, a Rede Nacional de Ensino e Pesquisa (RNP) tem se destacado desde o projeto Br6Bone. 
Atualmente toda a rede da RNP está apta a operar com o protocolo IPv6 em modo nativo, além de 


fornecer conexão IPv6 a instituições localizadas nos estados que se beneficiam de sua rede. A RNP 


também possui conexão IPv6 nativa com outras redes acadêmicas e comerciais. 


Representação do endereço IPv6 


Abreviação de zeros contínuos só pode ser feita uma vez em cada endereço IPv6. 

Certo: 

a 2001:0000:0000:0058:0000:0000:0000:0320 ou 

a 2001::58:0:0:0:320 ou 

a 2001:0:0:58::320 

Errado: 

a 2001::58::320 

Como foi dito, o endereço IPv6 é representado por 8 grupos de 16 bits separados por “:”. 
Nesta representação é permitido utilizar caracteres maiúsculos e minúsculos e regras de 
abreviação como: 

a Omitir os zeros à esquerda; 

a Representar os zeros contínuos por “::”. 


Exemplos: 


a 2001:0db8:0000:130F:0000:0000:087C:140b ou 
a 2001:0db8:0:130F::087C:140b 


® A abreviação de zeros contínuos só pode ser realizada uma única vez, caso contrário 


poderá haver ambiguidade na representação do endereço. 


Por exemplo, o endereço: 
2001:0000:0000:0058:0000:0000:0000:0320 pode ser abreviado como: 


2001::58:0:0:0:320 ou 2001:0:0:58::320, mas nunca na forma 2001::58::320 (errada!). 


o Prefixos de rede usam contagem de bits. 


Lo 


a Formato: endereco-IPv6/tamanho do prefixo. 


A representação dos prefixos de rede continua do mesmo modo que no IPv4, utilizando 
a contagem de bits. Esta notação é representada da forma “endereço-IPv6/tamanho do 
prefixo”, onde “tamanho do prefixo” é um valor decimal que especifica a quantidade de bits 


contíguos à esquerda do endereço, que compreendem o prefixo. 


Exemplos: 


a 2001:db8:3003::/48 
o 2001:db8:3003:2:a:20ff:fe18:4c/64 


Não há qualquer tipo de definição de classes de endereços como no IPv4. 


Tipos de endereços IPv6 


o Unicast. 
o Multicast. 


a Anycast. 
No IPv6 foram definidos 3 tipos de endereços: 


a Unicast -identifica apenas uma única interface; 


ao Multicast - identifica um grupo de interfaces e o pacote é enviado para todas as inter- 
faces do grupo; todos os nós devem suportar obrigatoriamente multicast; substitui o 


endereço broadcast: multicast “all nodes on link”: FFO2::1; 


o Anycast - também identifica um grupo de interfaces, porém o pacote é entregue apenas 


para a interface do grupo mais próxima do nó de origem. 


Transição de IPv4 para IPv6 


Técnicas de transição IPv4 para IPv6: 


Figura 4.41 --- --- 
Técnicas de 
transição de IPv4 
para IPv6. Pilha dupla Tunelamento Tradução 


Como não é possível substituir de uma hora para outra o protocolo IPv4 pelo protocolo IPv6 


em toda a internet, haverá necessidade de convivência entre os dois protocolos. 
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Figura 4.42 
Convivência entre 
IPv4 e IPv6. 





Para que a adoção do IPv6 seja bem-sucedida, é necessário que seja realizada de forma 
gradual e transparente para a maioria dos usuários. Desta forma, na fase inicial da transição 
haverá um período de coexistência entre os dois protocolos, em que redes IPv4 precisarão 
comunicar-se com redes IPv6 e vice-versa. 


Com o intuito de facilitar esse processo, foram desenvolvidas técnicas para manter a compa- 


tibilidade de toda a base das redes instaladas sobre IPv4 com o novo protocolo IPv6. 


As técnicas de transição podem ser classificadas nas seguintes categorias: 


à 


ao Pilha dupla - provê o suporte a ambos os protocolos no mesmo dispositivo. 


o Tunelamento - permite o tráfego de pacotes IPv6 sobre estruturas de rede IPv4, ou 


o inverso. 


o Tradução - permite a comunicação entre nós com suporte apenas a IPv6 com nós 
que suportem apenas IPv4 e vice-versa. 


Ausência de NAT no IPv6 


o Em IPv6 não existem endereços privados. 

a Não há necessidade de usar NAT em IPv6. 

a Os usuários devem usar redes com prefixo máximo /64, sem sub-redes. 
a Sub-redes só de prefixos menores que /64 (/48 ou /56). 

a Não haverá escassez de endereços IPv6 para as redes físicas. 


Em IPv6, não são definidos endereços privados da mesma forma que em IPv4. A ideia é que 
não haja escassez de endereços que justifique a adoção de NAT. Assim, os endereços IPv6 


poderão ser usados como endereços públicos, se for necessário. 


Recomenda-se que as menores redes dos usuários tenham prefixo /64. Se forem necessá- 
rias sub-redes, o usuário deverá receber um bloco maior (/48 ou /56). No caso de utilização 
de redes locais Ethernet, deve-se usar os 64 bits de identificação da estação para inserir o 
endereço MAC (48 bits). É premissa básica do endereçamento IPv6 que não haverá escassez 
de prefixos de rede e que os 64 bits de identificação da estação serão suficientes para qual- 
quer tamanho de rede física. 
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Figura 4.43 
Rede VLSM_ 
Exemplo 1. 


Roteiro de Atividades 4 


Atividade 4.1 - Configuração do exemplo 1 de VLSM 


1. Inicie o simulador Netsimk. 


2. Abra arquivo Rede Atividade4 1.nsw. Este arquivo contém a rede desenhada, mas não 


configurada. 


3. Configure o roteador e os computadores, um em cada sub-rede, obedecendo à seguinte 


distribuição: 
3.1. Sub-rede 192.168.10.0/25 na interface EO do roteador; 
3.2. Sub-rede 192.168.10.128/26 na interface E1; 


3.3. Sub-rede 192.168.10.192/26 na interface E2. 


Faça a configuração completa dos computadores: endereço IP, máscara de sub-rede e 


gateway padrão. 
A Figura 4.43 mostra a rede que deve ser configurada de acordo com as premissas acima. 


PC2 





Es 
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Atividade 4.2 - Estudo de caso 


Uma empresa recebeu do seu provedor a faixa de endereços IP, definida pelo prefixo 
200.10.10.0/24, para a construção de sua rede interna de computadores. Essa empresa é 
dividida em cinco departamentos (Produção, Compras, Vendas, Pessoal e Pesquisa) e cada 
um terá sua própria sub-rede IP. Considere que cada departamento conta com a seguinte 
quantidade de máquinas: Produção=10, Compras=25, Vendas=40, Pessoal=100 e Pes- 
quisa=8. Determine o prefixo de rede e o endereço de broadcast de cada departamento 
para que todas as máquinas recebam um endereço. Os prefixos devem ser alocados de tal 
forma que departamentos com um maior número de máquinas recebam endereços mais 
próximos do início do espaço de endereçamento disponível. Os prefixos devem ser infor- 
mados através da notação X.Y.W.Z/máscara, como na representação do prefixo fornecido 
pelo provedor (ENADE 2008, questão 39). 


Após efetuar os cálculos usando VLSM e o método BOX, configure a rede mostrada a seguir. 


PC3 





Configure na mesma ordem de cálculo das sub-redes: a maior sub-rede na interface EO, a 
segunda maior na interface E1 e assim por diante, até a menor sub-rede na interface E4. 
Inicie o simulador e abra a rede: Rede Atividade4 2.nsw. A rede está desenhada, mas não 
está configurada. 


Observe que o enunciado obriga a calcular as maiores sub-redes primeiro e as menores na 
sequência, exatamente como o algoritmo de atribuição de blocos. 


Atividade 4.3 - Configuração de NAT Estático e Dinâmico 


Um Provedor de Acesso à Internet (ISP) atribuiu a uma empresa a rede 199.99.9.32/27, que 
equivale a 30 endereços IP públicos. Como a empresa tem um requisito interno de mais de 
30 endereços, o gerente de TI decidiu implementar o NAT: os endereços 199.99.9.33 - 
199.99.9.39 para alocação estática e 199.99.9.40 - 199.99.9.62 para alocação dinâmica. 


Rota estátic O roteamento entre o ISP e o roteador da empresa RA é feito com o uso de uma rota es 


Rota definida pelo 
administrador da rede e 
inserida manualmente 
na tabela de rotas. 








; A conexão do ISP com a internet será representada por um endereço de loopback no roteador 
: RB (Figura 4.45). 





Rota padrão 


Rota usada pela estação 10.10.10.10 
ou roteador quando 


T 
y x 2 o 7 
o destino não está na Lim 
fal 
T 
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tabela de roteamento. 

































































10.10.10.20 
qe + 
PC2 RB 
Figura 4.45 
Configuração de 
NAT Estático e 
Dinamigo: 10.10.10.30 
Nome do roteador Tipo de interface Endereço IP Máscara de rede 
RA : Ethernet 0 É 10.10.10.1 | 255.255.255.0 
RA i Serial O i 200.2.2.18 i 255.255.255.252 
RB ! Serial 0 | 200.2.2.17 i 255.255.255.252 
RB : Loopback O i 172.16.1.1 i 255.255.255.255 


1. Inicie o simulador Netsimk e carregue a rede Rede_Atividade4_3.nsw. Os computadores 
PC1, PC2 e PC3 já estão configurados. É necessário configurar as interfaces dos rotea- 


dores e a tradução NAT. 
2. Os comandos de configuração do roteador RA estão listados abaixo. 
RA>en 
RA#conf t 
RA(config)#int e0 


RA(config-if)#ip address 10.10.10.1 255.255.255.0 





RA(config-if)#no shut 
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*LDXX - Line protocol on Interface Ethernet O, changed state to up 
RA(config-if)#int s0 

RA(config-if )#clock rate 64000 

RA(config-if)#ip address 200.2.2.18 255.255.255.252 


RA(config-if)#no shut 














RA(config-if)# 





RA# 
3. Os comandos de configuração do roteador RB estão listados abaixo. 
RB>en 


RB#conf t 


A) 


B(config)#int loopback0 


7 


B(config-if )#ip address 172.16.1.1 255.255.255.255 


se 


LDXX - Line protocol on Interface Loopback 0, changed state to up 


7 


B(config-if)#int sO 


72 


B(config-if)#ip address 200.2.2.17 255.255.255.252 


A) 


B(config-if)#no shut 


se 


LDXX - Line protocol on Interface Serial 0, changed state to up 


7 


B(config-if)# 





RB# 


Observe que o comando no shut “levanta” a interface, tanto em hardware como em sof- 
tware. Porém, as interfaces seriais conectadas a um link WAN dependem uma da outra. 
Depois que a interface serial de RB estiver configurada, a interface serial de RA ficará “up”. 


Basta olhar o console de RA para verificar que sO está “up”. 


Por outro lado, a interface “Loopback0” ficou no estado “up” assim que foi configurado o 
endereço, sem necessidade do comando no shut, porque ela é uma interface virtual e não 
depende do hardware para ser ativada. 


4. Crie uma rota estática do roteador do ISP para o roteador RA. Foram atribuídos os ende- 


reços 199.99.9.32/27 para acesso à internet fora da empresa. Use os seguintes comandos: 


RB#conf t 
RB(config)#ip route 199.99.9.32 255.255.255.224 200.2.2.18 
RB(config)#ex 


RB#sh ip route /* lista a tabela de rotas do roteador 


A tabela de rotas deve ser como a mostrada a seguir. 
C 172.16.1.1/32 is directly connected to Loopback 0 
S 199.99. 9.32/27 DIOJ yia 200.2,2.08 00:00:06 SO) 


C 200.2.2.16/30 is directly connected to Serial O 


5. Adicione uma rota padrão do roteador RA para o roteador RB do ISP. Isso encaminhará 


qualquer tráfego com endereço de destino desconhecido ao ISP. 

Use os seguintes comandos: 

RA#conf t 

RA(config)#ip route 0.0.0.0 0.0.0.0 200.2.2.17 

RA(config)#ex 

RA#sh ip route 
A tabela de rotas deve ser como a mostrada a seguir. 

C 200.2.2.16/30 is directly connected to Serial 0 

S= O.0.0.0/0 [1/00] via 200.2217 00:00:05 SO 

C 10.10.10.0/24 is directly connected to Ethernet 0 


Por que criamos uma rota padrão no sentido de RA para RB e uma rota estática no sentido 


oposto? Não poderia ser o mesmo tipo de rota nos dois sentidos? 











Para testar a continuidade entre a rede interna e o roteador RB do ISP, a partir do PC2 vamos 
digitar o comando ping para a serial O do roteador RB. O resultado deve ser parecido com o 


mostrado na listagem a seguir: 

Copie 200.22217 

Pinging 200.2.2.17 with 32 bytes of data: 
Ping request timed out. 

Ping request timed out. 


Ping request timed out. 

















Ping request timed out. 
(Cer 


Como podemos perceber, o ping não funcionou. A razão disso é que os endereços internos 
da rede 10.10.10.0/24 não são roteáveis na internet. Assim, o /CMP echo request chega até o 


RB, mas o /CMP Echo reply nunca retorna. Falta configurar a tradução NAT. 
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6. Para definir o conjunto de endereços IPv4 públicos utilizáveis para o NAT Dinâmico (reveja 


o enunciado desta atividade), use os seguintes comandos: 
RA#conf t 


RA(config)#ip nat pool nat_din 199.99.9.40 199.99.9.62 netmask 
ZO ORAS Oem aL a 


7. Para funcionar com NAT, o roteador Cisco RA exige que se defina um filtro dos endereços 
IPv4 internos que serão traduzidos para os endereços IPv4 públicos. Esse filtro chama-se 


“lista de acesso”. Esta lista faz o mesmo papel que o iptables no Linux. 
Use os seguintes comandos: 
RA(config)#access-list 1 permit 10.10.10.0 0.0.0.255 


Caso o endereço IP não esteja no intervalo 10.10.10.0 - 10.10.10.255, o pacote será descar- 
tado, porque no final de toda lista de acesso está implícito um deny. 


8. Vamos definir agora a tradução NAT Dinâmica da lista interna para o conjunto externo. 


Use os seguintes comandos: 


RA(config)#ip nat inside source list 1 pool nat din 
9. Para especificar as interfaces interna e externa do NAT, use os seguintes comandos: 
RA(config)#int e0 

RA(config-if)#ip nat inside 

RA(config-if)#int s0 

RA(config-if)#ip nat outside 


10. Repita o comando ping usado no item 5. Desta vez funciona, porque os endereços internos 
da rede 10.10.10.0/24 estão traduzidos em endereços públicos através do NAT dinâmico. 


Coping 200,2217 

Pinging 200.2.2.17 with 32 bytes of data: 
Reply from 200.2.2.17 on Eth, time<l0ms TTL=79 
Reply from 200.2.2.17 on Eth, time<lO0ms TTL=79 


Reply from 200.2.2.17 on Eth, time<l0ms TTL=79 











Reply from 200.2.2.17 on Eth, time<l0ms TTL=79 
(Cae 

11. Para verificar o mapeamento dinâmico use o seguinte comando: 
RA#sh ip nat translations 

12. Podemos então verificar as estatísticas com o seguinte comando: 
RA#sh ip nat statistics 

Os resultados devem ser semelhantes a listagem a seguir: 


RA#sh ip nat translations 


Pro Inside global Inside local Outside local 
Outside global 


=== 199,99,940 10, 10,1020 --- =e 


RA#sh ip nat statistics 
Total active translations: O (0 static, O dynamic; O extended) 
Outside interfaces: 

Serial 0 
Inside interfaces: 

Ethernet 0 
Hits: 4 Misses: 4 
Expired translations: 1 
Dynamic mappings: 

Blah blah blah (Sim currently does not show this info. Sorry.) 


RA# 


13. Configure o mapeamento estático para a estação de trabalho PC1, 10.10.10.10/24, que 
será designada como o servidor público WWW. Assim, ela precisa de um endereço IP 
público permanente para poder ser acessada pela internet. Deve ser usado um endereço 
do intervalo disponível para o NAT Estático. Use os seguintes comandos: 


RA#conf t 


RA(config)#ip nat inside source static 10.10.10.10 199.99.9.33 


14. Cheque a tabela de tradução para verificar o mapeamento, através dos seguintes 


comandos: 
RA#sh ip nat translations 
Deve aparecer o mapeamento da seguinte forma: 
Pro Inside global Inside local Outside local Outside global 


==> IQS) 99)..9).33) LOMO SOTO Sas se 


15. Verifique a configuração através de um ping da estação de trabalho 10.10.10.10 para o 
endereço 172.16.1.1 (loopback do roteador RB). Use o seguinte comando: 


ping 17216.11 


O ping funciona porque o endereço interno da rede 10.10.10.0/24 está traduzido no ende- 


reço público 199.99.9.33 através do NAT estático, conforme mostra a listagem a seguir. 
Ceryoring) M72 Mel 
Pinging 172.16.1.1 with 32 bytes of data: 


kepita noman E heme mes Om Small ES 29 
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Reply from 172.16.1.1 on Eth, time<l0ms TTL=/9 


Reply from 172.16.1.1 on Eth, time<l0ms TTL=79 





REO Trom 172-16-11 om Ech, cimeslOms TUL 
C> 


16. No roteador RB do ISP, faça ping no host com a tradução NAT estática usando o seguinte 
comando: 


ping 10.10.10.10 

O ping não é bem-sucedido porque o endereço interno da rede 10.10.10.0/24 não é roteável. 
RB#ping 10.10.10.10 

Type escape sequence to abort. 

Sending 5, 100-byte ICMP Echoes to 10.10.10.10. 

Timeout is 2 seconds: 

Success rate is 0% (0/5), round trip min/avg/max = 0/0/0 ms 

RB# 


17. No roteador RB do ISP, faça ping em 199.99.9.33. O ping funciona porque o endereço 
interno da rede 10.10.10.0/24 está traduzido no endereço válido 199.99.9.33, através do 
NAT estático, e esta entrada não expira na tabela de tradução. 


RB#ping 199.99.9.33 
Type escape sequence to abort. 


Sending 5, 100-byte ICMP Echoes to 199.99.9.33. 





Timeout is 2 seconds: 
Success rate is 100% (5/5), round trip min/avg/max = 19/21/23 ms 


RB# 


Protocolos de enlace 







Descrever o processo de criação e configuração de VLANs para segmentação de 





redes locais. Apresentar o protocolo STP e sua utilidade, e descrever o protocolo PPP 


e a tecnologia DSL de camada física. 


objetivos 












Protocolos de enlace no projeto de redes locais e de longa distância. Uso de VLANs 





na segmentação de redes Ethernet, configuração e roteamento; protocolos STP 


e PPP e tecnologia DSL de camada física, que fornece suporte às aplicações que 






$O1199U09 


usam o protocolo PPP. 


Fundamentos dos protocolos de enlace 


Este capítulo trata de protocolos de enlace que são importantes no projeto de redes locais e 
de longa distância. Inicialmente, será apresentada a utilidade de VLANs na segmentação de 
redes Ethernet, configuração e roteamento. Ser visto também o protocolo STP (Spanning Tree 
Protocol), que evita a ocorrência de loops em redes Ethernet com redundância de conexão 
entre switches. É abordado o protocolo PPP, usado em enlaces seriais dedicados e comutados 
em redes de longa distância. Também será abordada a tecnologia DSL de camada física, que 


fornece suporte às aplicações que usam o protocolo PPP. 


Rede local virtual (VLAN) 


a Conceitos VLAN. 

a VLAN Trunking/Tagging. 

o IEEE 802.1q. 

a Configuração de VLANs. 

a VLAN Trunking Protocol (VTP). 


o Roteamento Inter-VLAN. 





VLAN é um acrônimo de Virtual LAN (Redes Locais Virtuais), sendo um método para a 
criação de diversas redes lógicas independentes em uma mesma rede física: a VLAN só 


existe através de uma configuração de software do switch. 
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VLANs são configuradas tanto via hardware quanto via software, o que as tornam extrema- 
mente flexíveis, sendo uma forma simples de segmentar a rede Ethernet no switch, criando 
segmentos lógicos dentro de uma única rede física Ethernet. É claro que o switch deve ser 
capaz de suportar a configuração de VLANs; normalmente, são switches de alto desem- 
penho usados no ambiente de redes corporativas. 


Essa segmentação é feita na camada de enlace, independente dos endereços lógicos dos 
equipamentos (endereços de rede). Na prática, as VLANs se comportam de forma similar a 
diferentes redes físicas na camada de rede, necessitando de um roteador para encaminhar 
pacotes de uma VLAN para outra. 


O tráfego entre switches que participam de diversas VLANs é encaminhado via trunk links 
(enlaces tronco), através do protocolo IEEE 802.1Q. Para efeito de administração de VLANs, o 


protocolo VTP é usado para permitir o gerenciamento e configuração automática de VLANS. 


Conceito de VLAN 


a VLANs segmentam os domínios de broadcast. 
a VLANs se comportam de forma similar a diferentes redes físicas. 
a VLANs podem segmentar redes baseadas em switches. 


a VLANs são usadas para segmentar redes e proporcionar escalabilidade, segurança e 


facilidade de gerência. 
a VLANs se comunicam por meio de roteadores. 
a Os switches são interligados por VLAN trunks. 


Hosts conectados ao mesmo switch se comportam como se estivessem conectados a dife- 


rentes switches, ou seja, a LAN é construída não importando onde os equipamentos estejam fi Er 
5 a : sigs P igura >. 
localizados fisicamente. A Figura 5.1 exemplifica esse conceito. Conceito de VLAN. 




































































Sem VLANs Com VLANs 

10.1.0.0/16 10.1.0.0/16 

Engineering Engineering 
VLAN 

10.2.0.0/16 10.2.0.0/16 

Marketing Marketing 
VLAN 

Um link por VLAN 

10.3.0.0/16 ou um tronco 10.3.0.0/16 

Sales Sales 
VLAN 





























Accounting 
VLAN 10 
172.16.10.0/24 


Figura 5.2 
Exemplo de VLAN. 


VLAN trunk 


Função especial que 
pode ser associada a 
uma porta de switch, 
tornando-a capaz de 
transportar tráfego de 
qualquer VLAN da rede. 


Para entender melhor o papel das VLANS, é preciso rever as definições e as diferenças entre 


domínio de colisão e domínio de broadcast. 


a Dominio de colisão - área de uma rede Ethernet em que os quadros podem colidir uns 
contra os outros. Colisões podem ocorrer em redes baseadas em repetidores e hubs; 


mas não em redes baseadas em switches e bridges. 


o Dominio de broadcast - segmentação lógica de uma rede em que as estações recebem 
mensagens de broadcast. Deve-se diminuir a existência de grandes domínios de broad- 
cast, uma vez que este tipo de mensagem ocupa a banda da rede e as estações, aumen- 
tando o congestionamento, a latência e outros parâmetros nocivos à rede. Os domínios 
de broadcast são tipicamente restritos pelos roteadores, porque os roteadores não 


encaminham quadros de broadcast. 


Engineering Accounting Accounting Engineering Sales 
VLAN 20 VLAN 10 VLAN 10 VLAN 20 VLAN 30 
172.16.20.0/24 172.16.10.0/24 172.16.10.0/24 172.16.20.0/24 172.16.30.0/24 


Gigabit uplinks 


VLAN Trunk 





Características de uma VLAN: 


a Divide dominios de broadcast: o broadcast originado em uma VLAN não é recebido pelos 


computadores em outra VLAN, o que ajuda a melhorar o desempenho de uma rede grande. 


a Não há comunicação inter-VLAN: um equipamento presente em uma VLAN não consegue 
se comunicar com os equipamentos das outras VLANS: eles estão em sub-redes distintas, 
independentes. Porém, é possível que os hosts de diferentes VLANs se comuniquem 


através de um roteador ou de um switch L3 (com roteamento). 


a VLANs se comportam como redes distintas: se você tem a VLAN Ae aVLAN B, elas 
são consideradas redes completamente distintas, mesmo que estejam configuradas no 


mesmo switch. 


a Os switches são interligados por VLAN trunks que conduzem o tráfego de diversas 


VLANS entre eles. 


Operação de VLAN em sub-redes IP 


Broadcasts de camada 2 


a O que acontece quando o host 10.1.0.10 envia um “ARP Broadcast” para a rede 
10.1.0.0/16? 


m Resposta: o switch inunda todas as suas portas. 


a Mesmo os hosts estando conectados ao mesmo switch, os dispositivos em 





sub-redes diferentes podem se comunicar via roteador. 
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ARP 
Request 




















A) [A | 
10.1.0.10/16 10.2.0.20/16 10.1.0.30/16 10.2.0.40/16 Figura 5.3 
DG: 10.1.0.1 DG: 10.2.0.1 DG: 10.1.0.1 DG: 10.2.0.1 VLAN e sub-rede IP. 


O que acontece quando o host 10.1.0.1 envia um “ARP Broadcast” para a rede 10.1.0.0/16? 


a O switch inunda todas as suas portas; 

a Todos os hosts recebem broadcast, mesmo aqueles em sub-redes diferentes; 

o Broadcast de camada 2 deveria se propagar apenas em uma rede. 

Este efeito também acontece com unicasts desconhecidos, ou seja, endereços MAC que 
não estão na tabela MAC do switch. Se o switch suporta VLANs, por padrão todas as portas 
pertencem à mesma VLAN e o switch inunda todas as suas portas que pertencem à mesma 


VLAN da porta de entrada. Lembre-se de que um switch é um dispositivo de camada 2, que 


propaga pacotes tendo como base os endereços MAC, e não endereços IP. 


Neste caso, existe um único domínio de broadcast e cada pacote deste tipo será enviado 
para todos os computadores, independente da sua sub-rede. Se o usuário mudar o seu 
endereço IP, poderá participar sem restrições de qualquer sub-rede. 


Solução tradicional: múltiplos switches 


CJ 
a Asolução tradicional é ter dispositivos na mesma sub-rede conectados ao mesmo switch. 


o Proporciona segmentação de broadcast e unicast desconhecido, embora seja 


menos escalável. 


Figura 5.4 
ARP Request Solução tradicional. 









10.1.0.1/16 10.2.0.1/16 








Eq 
10.1.0.10/16 10.1.0.30/16 10.2.0.20/16 10.2.0.40/16 
DG: 10.1.0.1 DG: 10.1.0.1 DG: 10.2.0.1 DG: 10.2.0.1 





Cada switch funciona de modo independente e cada usuario se conecta ao switch do seu 
grupo/empresa. Além do custo maior pela aquisição de equipamentos adicionais, existe 
um desperdício de portas não utilizadas. O tráfego está isolado e os pacotes de broadcast 
trafegam somente no switch onde foram gerados, porque o roteador não propaga 


broadcasts de camada 2. 
Domínios de broadcast com VLANS e roteador 


o Uma VLAN é um domínio de broadcast criado por um ou mais switches. 


a Cada porta do switch pode ser designada para uma VLAN diferente. 


L- 


Port1 Port4 Port9 Port12 
VLAN 10 VLAN 20 VLAN 10 VLAN 20 


VLAN 10 VLAN 20 
Porta 1 : Porta 4 


Porta 9 : Porta 12 






ARP 
Broadcast 

















E EST EE 


10.1.0.10/16 10.2.0.20/16 10.1.0.30/16 10.2.0.40/16 
DG: 10.1.0.1 DG: 10.2.0.1 DG: 10.1.0.1 DG: 10.2.0.1 


Figura 5.5 a Portas designadas para a mesma VLAN estão no mesmo dominio de broadcast. 
Dominios de 


broadcast. o Portas em VLANs diferentes estão isoladas e em diferentes dominios de broadcast. 


As VLANS podem ser Estáticas ou Dinâmicas: 


o VLANs Estáticas - baseadas em portas; qualquer dispositivo que se conecte a uma 


determinada porta do switch pertence a uma determinada VLAN; 


o VLANs Dinâmicas - baseadas em endereços de enlace/rede (MAC/IP) ou credenciais do 
usuário. O administrador da rede deve previamente cadastrar os endereços MAC/IP das 
estações e associá-los às suas respectivas VLANS. Todos os pacotes com determinado 
endereço, independente da porta, serão enviados somente para os equipamentos que 


pertençam à VLAN. 
Configurando VLANS: 


a Estaticamente - administradores de redes configuram cada porta, que é associada a 
uma VLAN específica. O administrador é responsável por fazer o mapeamento entre as 


portas e as VLANS. 


oa Dinamicamente - as portas são capazes de resolver sua configuração de VLAN. Usam 
um banco de dados de endereços MAC/IP associados aos mapeamentos de VLANs, que 


devem ser configurados previamente pelo administrador da rede. 
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VLAN estática 


“Static membership VLANs” são chamadas de: 
o Port-based. 


a Port-centric membership VLANs. 
VLAN membership 


VLAN a qual uma dada 
VLAN membership da porta a qual esta conectado. estação pertence. 


Conforme um dispositivo ingressa na rede, ele automaticamente assume a 





Default Default 
VLAN 1 VLAN 1 


Figura 5.6 
Configurada Exemplo de 


VLAN 10 VLAN estática. 


a VLANs são definidas na porta do switch. 


o Para que um host seja parte de uma VLAN, ele deve possuir um endereço IP que pertença 


a sub-rede apropriada; este é o método mais comum de designar portas a VLANs. 


o AVLAN 1 é usada para gerência (VLAN default); todas as portas do switch pertencem a 


VLAN 1 por padrão, a menos que sejam explicitamente configuradas. 


a Lembre-se de que o conceito de VLAN está relacionado ao conceito de sub-rede, uma vez 


que ambas são subdivisões lógicas de uma mesma rede. 


VLAN dinâmica 


VLANs dinâmicas permitem que a filiação (membership) ocorra com base no endereço Cd 
MAC do dispositivo conectado à porta do switch. Quando um dispositivo ingressa na 

rede, envia uma consulta (query) para uma base de dados dentro do switch para obter 

sua “VLAN membership”. 


Figura 5.7 
Exemplo de 
VLAN dinâmica. 


São VLANs criadas por meio de software de gerência de redes e encontradas normal- 
mente em switches mais avançados. 


VLAN3 
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Endereço MAC checado 
no banco de dados 
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Servidor de configuração da VLAN 


Resumo dos tipos de VLAN: 


o Port-based - baseada nas portas físicas do switch/roteador. 


a MAC-based - baseada no endereço MAC da estação conectada. Neste caso, um computador 


será sempre associado à sua VLAN, independente da porta física a que esteja conectado. 


a Protocol-based - baseada no endereço de camada 3. Por exemplo: usa o endereço IP 
para associar o computador à sua VLAN, independente da porta física e do endereço 


MAC do computador. 


o Authentication-based - baseada nas credenciais fornecidas pelo usuário (ou dispositivo) 


usando o protocolo 802.1x. Os dispositivos são associados dinamicamente à VLAN. 


VLAN Tagging 


a 
Usado apenas quando um enlace entre switches precisa transportar tráfego de/para 
mais de uma VLAN. 


a Trunk link: conforme os quadros são recebidos pelo switch, vindos de qualquer 
estação de trabalho, a “Unique Packet Identifier” é adicionada a cada cabeçalho. Esta 


informação de cabeçalho designa a “VLAN membership” de cada pacote. 


Sem VLAN Tagging 


b 
VLAN1 é ae ; VLAN1 e > = VLANÍ 
— pt ee ts 
VLAN2 Sp VLAN2 => VLAN2 


Com VLAN Tagging 
MANTO qm e SEE TRUNK tm Mo 
Figura 5.8 iq > l 


Conceitode  ——————— i S : VLAN1 and VLAN2 koo u u a aeae 
"VLAN Tagging”. VLAN2 Sea i É VLAN2 


Sem “VLAN Tagging”, os enlaces que interligam os switches só transportam tráfego de uma 
única VLAN. Para transportar tráfego de mais de uma VLAN, é preciso usar “VLAN Tagging”. 


Usualmente, o backbone que interliga todas as VLANs da rede tem “VLAN Tagging” habilitado. 


VLAN2 VLAN3 b> pene “ee g 
oS? SESE 
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Figura 5.9 O pacote é entdo propagado para os switches ou roteadores apropriados com base no 


Exemplo de identificador de VLAN e no endereço MAC. 
“VLAN Tagging”. 
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Ao alcançar o “destination node” (switch), a VLAN ID é removida do pacote e este é enviado 
para a estação final. 


a Protocolos “trunking” foram desenvolvidos para efetivamente gerenciar a transferência 
de quadros provenientes de diferentes VLANs em um único enlace físico. 


a Os protocolos “trunking” negociam a distribuição de quadros para as portas associadas 
em ambas as extremidades do enlace. 


a “Trunk links” podem transportar tráfego para todas as VLANs ou somente para 


VLANS específicas. 


o Tag="etiqueta”. 


IEEE 802.10 


o IEEE 802.1Q é o protocolo padrão de trunking. 


a Garante a interoperabilidade entre switches, roteadores e servidores de 


diferentes fabricantes. 
o 802.1Q insere apenas 4 bytes adicionais no quadro Ethernet. 
o Atag 802.1Q é inserida pelo switch antes do envio do quadro para o “trunk link”. 


o Oswitch remove a tag 802.1Q antes de enviar o quadro para um enlace que não seja 


um “trunk link”. 






Trunking VLAN1 e VLAN2 
802.1Q 


Figura 5.10 
Protocolo IEEE 
802.1Q. 


O protocolo 802.1Q acrescenta o campo “Tag” (4 bytes) ao quadro Ethernet, atribuindo o valor 
0x8100 ao seu subcampo Tag Protocol ID (TPID). Para identificar a VLAN, são utilizados 12 bits 
(VLAN ID), permitindo a utilização de até 4094 VLANS diferentes. Antes da introdução do padrão 


802.1Q, existiam outros protocolos, como o Cisco's ISL (Inter-Switch Link, derivado do IEEE 


802.10) e o 3Com's VLT (Virtual LAN Trunk). Atualmente, o ISL não é mais suportado pela Cisco. 





Quadro Ethernet II. 
Tag 80210. 


E importante entender que um “trunk link” ndo pertence a uma VLAN especifica. A respon- 
sabilidade de um “trunk link” é de agir como um duto para VLANS entre switches, rotea- 


dores e servidores. 


Preambulo Destino Origem TPID Ethertype Dados FCS 
+ + q 





o o > V 
8 bytes 6 bytes 2 bytes 2 bytes 46-1500 bytes 4 bytes 


Figura 5.13 O cabeçalho de 4 bytes contém um Tag Protocol Identifier (TPID) e um Tag Control Information 
Quadro Ethernet II 


(TCI) com os seguintes propósitos: 
com IEEE 802.1Q. 


TPID 


TPID de 2 bytes com valor fixo de 0x8100. Este valor indica que o frame transporta informação 
dos protocolos 802.1Q e 802.1p. 


TCI 


o 3 bits com a prioridade do usuário (8 níveis de prioridade, de 0 a 7); 
o 1 bit de formato canônico: O = canônico e 1 = não-canônico. Veja a RFC 2469; 


o 12 bits contendo o identificador de VLAN (VID). 


A forma canônica, também conhecida como “formato LSB” e “formato Ethernet”, designa 

a maneira como os bits recebidos pelo adaptador LAN são mapeados em memoria: o 
primeiro bit de cada byte recebido é mapeado no bit menos significativo (mais à direita) na 
memória. A forma não-canônica, também conhecida como “formato MSB”, “formato IBM” e 
“formato Token-Ring”, designa o mapeamento inverso: o primeiro bit de cada byte recebido 


é mapeado no bit mais significativo na memória (mais à esquerda). 


IEEE 802.1ad (QinQ) 


a 
Permite o transporte de VLANs dentro de outra VLAN, sendo utilizado em redes metro- 


politanas para transporte das redes dos clientes. | 


A especificação original do protocolo 802.1Q permite que um único cabeçalho de VLAN seja 
inserido num quadro Ethernet. QinQ permite que múltiplos cabeçalhos de VLAN sejam inse- 
ridos num único quadro Ethernet. Essa é uma facilidade essencial para a implementação de 
redes Metro Ethernet (Redes Metropolitanas Ethernet). Nesse contexto, o termo “VLAN tag” é 
comumente usado no lugar de “802.1Q VLAN header”. QinQ permite múltiplos VLAN tags num 
quadro Ethernet, criando uma pilha de tags. Usualmente, um quadro QinQ é um quadro que 
tem 2 cabeçalhos VLAN 802.1Q (duplo tag), um para a rede VLAN de um determinado cliente e 


outro para a rede metropolitana que transporta o tráfego de VLANS de vários clientes. 
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Frame 
Destination Source Lenght/ Check 
address address EtherType Sequence 


Original 
customer network 
Figura 5.14 
oe tone anes 


GARP VLAN Registration Protocol (GVRP) 


a Aplicação do protocolo GARP. 

ao Permite a descoberta automática de informações de VLANs. 
o Torna desnecessária a configuração manual de switches. 

ao Definido pela norma ISO/IEC 15802-3. 


Para que as redes locais virtuais encaminhem os pacotes para o destino correto, todos os 
switches pertencentes a elas devem conter a mesma informação em suas respectivas bases 
de dados. O protocolo GVRP permite que estações e switches com suporte ao IEEE 802.1Q 
editem e revoguem membros de uma VLAN. Os switches também são responsáveis por 
registrar e propagar os membros de uma VLAN para todas as portas que participam da atual 
topologia da VLAN. A topologia de uma rede é determinada quando os switches são ligados 


ou quando uma modificação é percebida no estado da topologia corrente. 


O objetivo principal do GVRP é permitir aos switches a descoberta automática de algumas infor- 
mações das VLANS, para evitar a configuração manual de cada switch. Isto é possível usando 








Para mais informações, 
consulte a norma IEEE 
Std 802.1Q-1998. 


GARP (Generic Attribute Registration Protocol) para propagar os atributos de identificação de 
VLANS através de uma rede local formada por switches (bridged LAN). GVRP também pode 
rodar em servidores de redes. Esses servidores usualmente são configurados para participar de 


várias VLANS, sinalizando para os switches da rede que desejam participar das VLANS. 


GVRP é uma aplicação do protocolo GARP, cujo objetivo é fornecer um framework genérico 
pelo qual dispositivos numa LAN formada por switches podem registrar e cancelar entre si 
valores de atributos, tais como identificadores de VLAN. GARP define a arquitetura, regras 


de operação, máquinas de estado e variáveis para o registro e cancelamento dos valores de Máquina de estado 


atributos. GARP é definido pela norma ISO/IEC 15802-3. Qualquer dispositivo 
que armazena o status 
de algo num dado ins- 
tante e pode processar 
entradas que mudam o 
status e/ou provocam 
uma ação ou saída para 
uma dada modificação. 
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VLAN Trunking Protocol (VTP) 


a Gerenciamento da configuração de VLANs. 
a Administrador adiciona, exclui e renomeia VLANs. 
ao As informações são propagadas a todos os switches. 
ao Benefícios do VTP: 
a Consisténcia da configuração de VLANs na rede. 
a “VLAN trunking” em redes mistas (ATM Lane, FDDI....). 
m Monitoração das VLANs com registro acurado. 
m Informação das VLANs adicionadas. 


m Adição de VLANs plug-and-play. 





a Protocolo proprietário da Cisco. 


ao Protocolo que gerencia a configuração de VLANs especificamente para auxiliar 


o administrador de rede; 
ao Só deve ser utilizado quando existirem várias VLANs numa mesma rede; 
a Não tem sentido usar VTP numa rede com apenas uma VLAN; 
ao As informações do protocolo VTP são enviadas aos switches via “trunk links”; 
a Todos os switches devem pertencer ao mesmo dominio VTP; 
a É necessário configurar um servidor VTP; cada servidor define um dominio VTP; 


o Switches de diferentes dominios VTP não trocam informações entre si. 
Modos de operação VTP 


Existem 3 diferentes modos de operação em um domínio VTP: 
a Servidor (Server). 
a Cliente (Client). 


a Transparente (Transparent). 


Servidor 

Este é o modo default de operação dos switches em geral. É necessário ter um servidor no 
domínio VTP para propagar a informação das VLANs em todo o domínio. O switch precisa 
estar no modo servidor para ser capaz de criar, adicionar ou excluir VLANs num domínio 
VTP. As alterações de configuração de VLANs têm que ser feitas no modo servidor e essas 


alterações serão propagadas para todo o domínio VTP. 


Cliente 

No modo cliente, os switches recebem informações dos servidores VTP, e também enviam 
e recebem as alterações de configuração, mas não podem efetuar nenhuma modificação. 
Nenhuma das portas de um switch cliente pode ser adicionada a uma nova VLAN antes de 


receber a notificação do servidor VTP. 


Transparente 

Switches neste modo de operação não participam do domínio VTP, mas ainda encaminham 
os anúncios dos servidores pelos “trunk links”. Estes switches não podem adicionar ou 
excluir VLANS, porque eles têm seu próprio banco de dados, que não é compartilhado com 


os outros switches. Este banco de dados é considerado de significado local. O objetivo deste 
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modo é permitir que switches remotos recebam as informações dos servidores VTP através 


de um switch que não participa da mesma configuração de VLANS. 


Configurando VLANs 


Designando portas para a VLAN: 
Switch(config)#interface fastethernet 0/9 
Switch(config-if)#switchport access vlan 10 
Switch(config-if)#switchport mode access 
A opção “access” configura a porta como uma porta de acesso, e não como um “trunk link”. 


A sequência de comandos mostrada exemplifica a designação da porta 9 a VLAN 10. As demais 


portas permanecem designadas à VLAN 1, por default, conforme mostrado na Figura 5.15. 





Default Default 
VLAN 1 VLAN 1 Figura 5.15 
Exemplo de configu- 
VLAN 10 ração de VLANS. 


Em equipamento Cisco, usando o simulador Netsimk, todas as portas são configuradas por 
default como “switchport mode dynamic desirable”, o que significa que se a porta for 
conectada a outro switch, com uma porta configurada no mesmo modo default (ou 


“desirable” ou “auto”), este enlace se tornará um “trunking link”. 
Comandos recomendados: 
switchport access vlan 


switchport mode access 


Configuração de VLANS estáticas 


As instruções seguintes devem ser observadas na configuração de VLANs em switches L2: 
a O número máximo de VLANs depende do switch. 
a VLAN 1: 

m Uma das VLANs default. 

m Naverdade é a Ethernet VLAN default. 

m Usada para gerência. 


Em geral, os switches permitem a configuração de 4.094 VLANs. A VLAN 1, por default, é 
utilizada para gerência. Com já apresentado no exemplo anterior, os comandos a seguir são 
usados para designar “access ports” (non-trunk ports) para uma VLAN específica: 


Switch(config)#interface fastethernet port number 
Switch(config-if)#switchport access vlan vlan number 


Switch(config-if)#switchport mode access 


Figura 5.16 
Exemplo de 
configuração de 
faixas de VLANs. 


Configurando faixas de VLANs 





VLAN 2 VLAN 3 


O exemplo mostrado a seguir ilustra a configuração das VLANs 2 e 3. Na VLAN 2, as portas 5, 
6 e 7 são individualmente configuradas. No caso da VLAN 3, a faixa de portas de 8 até 12 é 


incluída em um único comando. 

Configurando a VLAN 2: 

Switch(config)#interface fastethernet 0/5 
Switch(config-if)#switchport access vlan 2 
Switch(config-if)#switchport mode access 

Switch(config-if)#exit 
Switch(config)#interface fastethernet 0/6 
Switch(config-if)#switchport access vlan 2 


Switch(config-if)#switchport mode access 


ct 


Switch(config-if)#exi 
Switch(config)#interface fastethernet 0/7 
Switch(config-if)#switchport access vlan 2 


Switch(config-if)#switchport mode access 





ct 


Switch(config-if)#exi 
Configurando a VLAN 3: 
Switch(config)#interface range fastethernet 0/8 - 12 
Switch(config-if)#switchport access vlan 3 
Switch(config-if )#switchport mode access 


Switch(config-if )#exit 


® Este formato de comando pode variar um pouco de switch para switch, mas é 


comum que possua a funcionalidade da definição de VLANs por faixas de portas. 


No caso de switches Cisco, o comando switchport mode access deve ser configurado em todas 


as portas que o administrador não queira que se transformem em portas tronco. 
Verificando VLANs - comando show vlan 


O comando show vlan é usado para identificar as VLANs configuradas e suas respectivas 


portas associadas. 
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VLAN 1 VLAN 2 VLAN 3 Figura 5.17 


default Comando show vian. 
Switch#show vlan 
VLAN Name Status Ports 
VLAN Name Status Ports 
1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4 
2 VLAN2 active Fa0/5, Fa0/6, Fa0/7 
3 VLAN3 active Fa0/8, Fa0/9, Fa0/10, Fa0/11, 
Fa0/12 
1002 fddi-default active 


1003 token-ring-default active 
1004 fddinet-default active 


1005 trnet-default active 


VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Transl 
Trans? 


1 enet 100001 1500 - z E S = 1002 1003 

2 enet 100002 1500 - = 5 = = 0 0 
Como pode ser observado, outras VLANs default sdo criadas para ambientes “ndo-Ethernet”: 
1001, 1002, 1003, 1004, 1005. 


Removendo VLANs 


Estes comandos removem a interface especificada da VLAN indicada, voltando a configu- 
ração default da interface para VLAN 1: 


Switch(config)#interface fastethernet port number 
Switch(config-if)#no switchport access vlan vlan number 


AVLAN 1 ndo pode ser removida do switch. 


Apagando informações de VLAN 


Informações das VLANs são mantidas num arquivo “vlan.dat”. O arquivo não é apagado quando 
apagamos a “startup-config” (configuração inicial carregada por ocasião do boot no switch). Esse 


procedimento é usado em equipamentos Cisco (exemplo com o simulador Netsimk). 

Para apagar a “startup-config”, removendo as informações de VLAN, use os seguintes comandos: 
Switch#delete flash:vlan.dat 

Delete filename [vlan.dat]? 

Delete flash:vlan.dat? [confirm] 

Switch#erase startup-config 


Switch#reload 





O ultimo comando executa re/oad no switch. 


Acessando e gerenciando o switch 


a 
Endereço IP, máscara de sub-rede e default gateway em switch de camada 2 servem para 


o mesmo propósito de quando configurados num host: acessibilidade. | 


O switch é um dispositivo de camada de enlace gerenciavel através de protocolos de camada 
de rede como o IP, por exemplo. Para gerenciar um switch, é preciso definir endereço IP, 
gateway padrão, máscara de sub-rede, da mesma forma que fazemos com hosts PC. Para 


fazer isso usamos a interface VLAN 1. 


Por default, VLAN 1 é a VLAN de gerência; é nela que atribuímos o endereço IP e a máscara 
de sub-rede ao switch. Este endereço é apenas usado para gerência, e não afeta as opera- 


ções de comutação dos quadros do switch (comutação de camada 2). 

Os seguintes comandos são usados para configurar o endereço IP e o gateway default do switch: 
Switch(config)#interface vlan 1 

Switch(config-if)#ip address 10.1.0.5 255.255.0.0 

Switch(config-if)#no shutdown 

Switch(config-if)#exit 

Switch(config)#ip default-gateway 10.1.0.1 

O endereço IP permite testar a conectividade (ping) ou acessar o switch por telnet. 


O gateway default também é usado com a finalidade de gerência; uma vez tendo acessado 
o switch (por telnet, por exemplo), se for preciso usar o comando ping ou telnet em qualquer 


outro dispositivo da rede, os quadros serão enviados para o gateway default configurado. 


O switch deve ser configurado com um login/senha de VTY e uma senha com privilégio para 


acesso telnet. 


Configurando trunking 


O comando seguinte configura “VLAN Tagging” em uma interface: 


L_ 


Switch(config-if)switchport trunk encapsulation [dot1q|is!] 
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As duas opções são: 
o dotig (IEEE 802.10) 
o isl (ISL) 


O protocolo de trunking deve ser o mesmo nas duas extremidades. 


wan , k = = : Ne =. : VLAN1 


— >. ie VLAN1 and VLAN2 Ri 
VLAN2 ea > Oe, RR 
Figura 5.18 
Configuração 
de trunk. 


Switch(config-if)# switchport trunk encap ? 


dotlq Interface uses only 802.1q trunking encapsulation when 
trunking 


isl Interface uses only ISL trunking encapsulation when trunking 


O comando a seguir permite definir explicitamente se uma determinada porta vai operar 
no modo “access” (só permite tráfego de uma VLAN) ou no modo “trunk” (permite tráfego 
de varias VLANs). 


Switch(config-if)switchport mode [access | trunk] 


Por default, switches Cisco “2900XL switchports” são configurados como access ports - não Access port 


vale para a maioria dos switches, em que o default é dynamic desirable. Significa que a porta 
(interface) pode per- 

“Access ports” (porta no modo acesso) podem ser usadas quando: tencer somente a uma 
única VLAN. 


ao Apenas um único dispositivo esta conectado à porta; 


a Múltiplos dispositivos (hubs) estão conectados a esta porta, todos pertencentes à 
mesma VLAN; 


a Outro switch está conectado a esta interface, mas o enlace está transportando apenas 
uma única VLAN (non-trunk link). 


Já “Trunk ports” (porta no modo tronco) são usadas quando outro switch está conectado a 


esta interface, e este link está transportando múltiplas VLANs (trunk link). 


Roteamento Inter-VLAN 


“trunk links”. Embora a medida proporcione balanço de carga entre VLANs, pode não | 


Uma opção é usar um link separado no roteador para cada VLAN ao invés de utilizar 


oferecer um uso eficiente em links com pouco tráfego. 


Figura 5.19 
Exemplo de rotea- 
mento inter-VLAN. 


Figura 5.20 
Conceito de 
interfaces lógicas 
num roteador. 








Ea 


10.10.0.11/16 10.20.0.22/16 


a 


VLAN 10 VLAN 20 


FastEthernet 0/0 af. FastEthernet 0/1 


10.10.0.1/16 `, 4 10.20.0.1/16 


Quando um nó em uma sub-rede ou VLAN necessita comunicar-se com um nó em outra sub-rede 
ou VLAN, um roteador torna-se necessário para rotear o tráfego entre as VLANS. O roteador 
deve ter portas configuradas em todas as VLANS que se deseja interligar. 

o Verifique os endereços IP associados à VLAN; 

a Muitas configurações utilizam o número da VLAN no endereço IP para facilitar a identificação; 


a Um switch L3 é capaz de rotear os pacotes sem a necessidade de um roteador. 


Interfaces lógicas 


múltiplas interfaces lógicas. | 


Subinterfaces num roteador podem ser usadas para dividir uma interface fisica em 


4 
4 
+? 


FastEthernet 0/0 FastEthernet 1/0 


802.1q 


-@ FastEthernet 1/0.2 O 


- 6 FastEthernet 1/0.1 
-@ FastEthernet 1/0.3 


= ISL/802.1q 






A RES ISL/802.1q 


~ m | 
=“ im 
com ISL/802.1q + ay 






PRP Subinterface 


Physical Interface 


Alguns roteadores permitem a configuração de subinterfaces ou interfaces virtuais. Em 
equipamento Cisco, usando o simulador Netsimk, o seguinte comando configura a interface 


especificada como uma interface virtual: 


Rtr(config)#interface fastethernet port/interface.subint 
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Roteamento Inter-VLAN - trunk links 
Rtr(config)#interface fastethernet 0/1.1 
Rtr(config-subif)#description VLAN 1 
Rtr(config-subif )#encapsulation dotlq 1 
Rtr(config-subif)#ip address 10.1.0.1 255.255.0.0 


Em roteadores que permitem configuração de subinterfaces ou interfaces, recomenda-se 
que as subinterfaces tenham o mesmo número da VLAN associada. A Figura 5.21 mostra um 
exemplo de configuração de subinterfaces para que o roteador possa efetuar o roteamento 
entre as VLANs 10 e 20. 


FastEthernet 0/0 


ASK 


10.10.0.11/16 VLAN 10 VLAN 20 








10.20.0.22/16 


FastEthernet 0/1 


10.1.0.1/16 A 4 Figura 5.21 


SE ; Exemplo de 
~ ` Router-on-a-Stick P 
10.10.0.1/16 A ye configuração de 
10.20.0.1/16 > a interfaces lógicas. 
A interface física é a FastEthernet0/1 e as subinterfaces são, respectivamente: 


a 0/1.10 - associada à VLAN 10; 
a 0/1.20 - associada à VLAN 20. 


Observe que a VLAN 10 tem o prefixo de rede 10.10.0.0/16, e a VLAN 20 tem o prefixo de 
rede 10.20.0.0/16. Além de configurar as subinterfaces, uma para cada VLAN, é necessário 
ainda configurar a interface física (0/1) no modo “trunk link”, para que possa transportar 
tráfego de ambas as VLANs em um único enlace físico. Esse tipo de configuração é chamado 
de “Router-on-a-Stick”. 


Configurando o roteador: 
Rtr(config)#interface fastethernet 0/1.10 


Rtr(config-subif)#description Management VLAN 10 


wa 


tr(config-subif )#encapsulation dotlq 10 


Rtr(config-subif)#ip address 10.10.0.1 255.255.0.0 


29 


tr(config)#interface fastethernet 0/1.20 


o) 


tr(config-subif )#description Management VLAN 20 


tr(config-subif)#encapsulation dotlq 20 

















wa 


tr(config-subif)#ip address 10.20.0.1 255.255.0.0 
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Configurando o switch: 
switch(config)#interface FastEthernet 0/0” 
switch(config-if)#switchport trunk encapsulation dotlq 


switch(config-if )#switchport mode trunk 


Spanning Tree Protocol (STP) 


Zi 
STP frequentemente representa mais do que 50% da configuração, resolução de pro- 

blemas e dores de cabeça na manutenção de redes reais (especialmente as mal proje- 
tadas). É um protocolo complexo e geralmente mal compreendido, que tem o propósito 


de evitar e eliminar loops na rede. Conceitos chave em STP: 

o Bridge ID. 

a Custo do Caminho. 

Será apresentado o algoritmo em que se baseia o STP e a forma como ele contribui para 


um projeto adequado de redes que inclua as devidas redundâncias na busca por um 


desempenho satisfatório. 
Sobre o STP: 


a É um protocolo de prevenção de loops; 
a Usa o algoritmo Spanning Tree; 
ao Permite que dispositivos L2 comuniquem-se com outros para descobrir loops físicos na rede; 


a Cria uma estrutura de “árvore com ramos e folhas” sem loops, que se espalha por toda a 


rede de camada 2. 


Se não existissem loops, STP teoricamente deveria ser desabilitado, pois o algoritmo aumenta 
o tempo regular de convergência das portas. Entretanto, é perigoso desabilitá-lo, pois a qual- 


quer momento um enlace redundante pode ser intencional ou acidentalmente configurado. 


Protocolo Spanning Tree 


a Loops podem ocorrer como parte do projeto dentro de uma estratégia de redundância. a 
o STP não é necessário se não houver loops na rede, mas é bom deixá-lo habilitado. 

a Loops podem ocorrer acidentalmente. 

Um bom projeto de redes prevê redundância de enlaces entre os principais switches de 
distribuição e de core, a fim de garantir maior disponibilidade e confiabilidade das redes. 

a A redundância gera loops (mais de um caminho entre dois dispositivos); 


ao STP é usado para resolver esses loops. 


Loops na rede 

Os switches alternarão os estados das tabelas de comutação para estação 
A (criando elevado uso de CPU). L2 loops podem causar: 

o Tempestade de broadcast. 

a Múltiplas cópias dos quadros Ethernet. 


o Instabilidade da tabela de endereços MAC. 
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A Figura 5.22 ilustra o conceito de tempestade de broadcast (broadcast storm), uma 
condição de sobrecarga na rede ocasionada pelo tratamento incorreto de um quadro de 
broadcast, fazendo com que os switches repliquem indefinidamente o quadro, o que faz o 
problema crescer exponencialmente, tornando-o crítico. 


Estação A 






Segmento A 


Segmento B 


Figura 5.22 
Estação B Tempestade de 
broadcast. 


o Loops L2 podem ocorrer sempre que houver um caminho redundante ou loop na rede 
de camada 2. 


o Broadcasts e loops de camada 2 podem ser uma combinação perigosa. 


a Quadros Ethernet não possuem campo de TTL (Tempo de Vida) para controlar o tempo 
do quadro na rede. 


a Depois de ocorrido um loop, quadros Ethernet continuam a se propagar indefinidamente, 
até que alguém desligue os switches ou interrompa os links. Essa propagação indefinida 
pode simplesmente travar todo o tráfego de um switch. 


A Figura 5.23 ilustra um cenário no qual um quadro em unicast é indefinidamente replicado 
nas portas dos switches: 


1. Switch Moe aprende endereço MAC de Kahn; 


2. MAC de destino é um endereço unicast desconhecido (unknown). Assim, Moe “inunda” 


este quadro unicast por todas as suas portas; 


3. Switch Larry recebe o quadro duas vezes, mas grava apenas o MAC de origem do quadro 
recebido por último; 


4. Switch Larry inunda o quadro unicast com MAC de destino desconhecido por todas as 


suas portas, exceto a porta de entrada; 


5. Switch Moe recebe o quadro, muda a tabela de endereços MAC com a nova informação e 


inunda o quadro unicast com MAC de destino desconhecido para todas as suas portas; 


6. E assim o ciclo continua indefinidamente. 
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Figura 5.23 
Exemplo de 
tempestade 
de broadcast. 


Broadcast de camada 2 




















SAT (Source Address Table) SAT (Source Address Table) 
Porta A: 00-90-27-76-96-93 Porta 4: 00-90-27-76-96-93 
Após passo 4, 6, ... Após passo 1 








SAT (Source Address Table) 
Porta B: 00-90-27-76-96-93 














Supondo que o quadro foi recebido 
Baran por último na porta B 


00-90-27-76-5D-FE 


Outro possível cenário problemático ocorre quando uma estação envia um quadro em 
broadcast. Por exemplo: 
7. Host Kahn envia uma solicitação ARP, um broadcast de camada 2 (layer 2); 


8. Switches Moe e Larry inundam todas as portas com o quadro, e continuam a inundar 


quadros duplicados e constantemente mudam suas tabelas de endereço MAC. 
Uso de STP para evitar loops 


am 
O propósito do STP é evitar e eliminar loops na rede ao negociar um caminho sem loop 


(loop-free) através da ponte raiz (root bridge). _| 


O Spanning Tree Protocol (STP) determina se ha loops e bloqueia links redundantes, assegu- 


rando que haverá apenas um caminho ativo para cada destino. 


O Spanning Tree Algoritm (STA) escolhe um ponto de referéncia, chamado de “root bridge”, 
e determina os caminhos disponiveis a partir do ponto de referéncia. Se existirem mais de 


dois caminhos, STA escolhe o melhor caminho e bloqueia os demais. 
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Distribuição 1 , Distribuição 2 











Acesso 1 Acesso 2 
No exemplo, o segmento do switch “Núcleo” para o “Distribuição 1” será bloqueado, ficando Figura 5.24 
disponíveis os segmentos entre os switches “Núcleo” e “Distribuição 2” e entre “Distribuição 2” P loop 
e switches. 
e “Distribuição 1”. 
Conceitos chave em STP 
Cálculos STP fazem uso extensivo de dois parâmetros: 
o Bridge ID (BID). 
a Custo do Caminho (Path Cost). 
Bridge ID - 8 Bytes 
Prioridade 
da bridge Endereço MAC 
2 Bytes 6 Bytes 
Velocidade do link Custo (especificação Custo (especificação 
IEEE revisada) IEEE anterior) 
10 Gbps 2 | 
1 Gbps a E 
100 Mbps ; 19 : 10 Figura 5.25 
10 Mbps : 100 : 100 oie usa 
: : do enlace. 


Quanto maior a velocidade, menor o “custo” associado ao algoritmo. 


a Este princípio é usado no desenvolvimento de uma topologia “loop-free”. 


a Originalmente, IEEE802.1D definiu custo como 1000 Mbps/(banda do enlace em Mbps). 
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Figura 5.26 
Detalhamento 
da BID. 


a Custo de link de 100 Mbps = 10 ou 1000/100. 
a Custo de link de 1 Gbps = 1 ou 1000/1000. 


No entanto, em função do aumento das taxas de transmissão das redes Ethernet, os custos 
foram revisados, permitindo diferenciar redes com taxas de 1Gbps e 10Gbps, conforme 


ilustrado na Figura 5.25. 
Bridge ID 


Vá 
Usado para identificar cada bridge/switch e para determinar a raiz da rede (root bridge). 


Bridge ID - 8 Bytes 


Bridge ID 


Prioridade 
sem sistema ID estendido da bridge Endereço MAC 


2 Bytes 6 Bytes 





Bridge ID - 8 Bytes 
Bridge ID 


Prioridade ID Sistema End MAC 
com sitema ID estendido da bridge estendido ndereço 





4 Bits 12 Bits 48 Bits 


O Bridge ID (BID) consiste de dois componentes: 


a Bridge Priority (2 bytes): switches Cisco adotam por default o valor 32,768 ou 0x8000. 
oa Endereço MAC de 6 bytes. 


Bridge Priority é expresso usualmente em formato decimal e o endereço MAC na BID é 
usualmente expresso em formato hexadecimal. O protocolo Spanning Tree requer que cada 


switch tenha um único identificador BID. 


No padrão original IEEE802.1D, o BID era composto por um campo “Priority” e o endereço 
MAC do switch. Todas as VLANs eram representadas por uma Common Spanning Tree (CST). 


PVST (Per-Vlan ST) requer que uma instância separada de Spanning Tree exista para cada 
VLAN. O campo BID necessita transportar informação de VLAN ID (VID), o que é possibili- 
tado pela reutilização de uma parte do campo “Bridge Priority” (prioridade), denominado 


sistema estendido de identificação (extended system ID). 


O BID é utilizado para eleger a “root bridge”. O switch que possui o menor valor de “Bridge 
ID” é selecionado como “root bridge”. Se todos os dispositivos tiverem a mesma prioridade, 
o switch com o menor endereço MAC se torna a “root bridge”. Por simplicidade, nas nossas 


topologias, usaremos “bridge priorities” sem o “Extended System ID”. 
Custo do caminho 


a 
a Switches usam o conceito de custo para avaliar a sua “proximidade” em relação aos demais. 
o Pode-se alterar o custo do caminho mudando o custo da porta (cuidado ao fazer isso). 


o BID e Custo do Caminho (Path Cost) são usados para determinar uma topologia “loop-free”. 


O custo de um enlace é um conceito usado para avaliar a proximidade entre switches. Esse 
custo pode ser alterado usando comandos de configuração apropriados, mas deve ser 
usado com cautela, porque isso modifica o resultado dos cálculos de uma topologia isenta 
de loops (loop-free). A identificação do BID e do custo do caminho são elementos usados 


para a determinação de uma topologia isenta de loops. 
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A IEEE modificou a Spec ao usar uma nova escala não linear: 


Velocidade do link Custo 
4 Mbps 250 
10 Mbps 100 
16 Mbps 62 
45 Mbps 39 
100 Mbps 19 
155 Mbps 14 
622 Mbps 6 

1 Gbps 4 

10 Gbps | 2 


Sequência de decisão de 5 passos 


Na escolha dos melhores caminhos, STP sempre usa a mesma sequência de decisão 


de 5 passos: 


Passo 1 - Menor BID. 

Passo 2 - Caminho de menor custo até a “root bridge”. 
Passo 3 - Origem de menor BID. 

Passo 4 - Menor prioridade de porta. 


Passo 5 - Menor identificador de porta. 


Bridges e switches usam BPDUs de configuração durante este processo. 


Bridge Protocol Data Unit (BPDU) 


Bridges armazenam uma cópia das melhores BPDUs vistas em cada porta. 


Ao fazer esta avaliação, consideram-se todas as BPDUs recebidas na porta, como 
também as BPDUs que seriam enviadas da porta. 


Cada BPDU que chega é verificada de acordo com os 5 passos, para saber se é mais atra- 
tiva (menor em relação aos valores dos itens avaliados em cada passo da sequência de 
decisão) do que a BPDU existente armazenada para aquela porta. 


Somente a BPDU mais atrativa é armazenada. 


Bridges enviam BPDUs de configuração até que uma BPDU mais atrativa seja recebida. 


Convergência STP 


Passo 1 - Eleger uma “root bridge”. 

Passo 2 - Eleger as “root ports”. 

Passo 3 - Eleger as “designated ports”. 

Uma “root port” numa bridge é a porta mais próxima da “root bridge”. 
Bridges usam custo para definir proximidade. 

Toda “non-root bridge” seleciona uma “root port”. 


Bridges calculam o “root path cost”, o custo acumulado de todos os links para a “root bridge”. 


Figura 5.27 
Especificação IEEE 
para custos de link. 


O protocolo STP tem por objetivo a eliminação de loops numa rede com enlaces redundantes 
entre switches. O protocolo não elimina esses enlaces redundantes, necessários para aumentar 
a confiabilidade da rede em caso de falhas de cabeamento, mas desabilita os enlaces que pro- 


vocam loops que podem “derrubar” a rede por causa das tempestades de broadcast. 
Para atingir esse objetivo, o protocolo tem um algoritmo de 3 passos: 


a Passo 1 - Eleição de uma “root bridge” (ponte raiz); 


ao Passo 2 - Eleição das “root ports” (portas raiz) que, na perspectiva de cada switch, têm o 


caminho de menor custo até a ponte raiz; 


a Passo 3 - Eleição das “designated ports” (portas designadas) que, na perspectiva de cada 


segmento, têm o caminho de menor custo até a ponte raiz. 


Os passos 2 e 3 são executados em todas as bridges, exceto a root bridge, que é única na 
rede e serve de base para o algoritmo. Para executar estes passos, é utilizado o custo dos 
enlaces entre as bridges. A seguir é apresentado um exemplo para eleição da root bridge, 


“root ports” e “designated ports”. 


Eleição da “root bridge” 


El 
O algoritmo STP usa 3 passos simples para convergir numa topologia “loop-free”. Eleição 
da “root bridge”: 


ao Determina o caminho mais curto à “root bridge” e as portas que propagarão quadros. 
o Tudo é feito com BPDUs enviadas a cada 2 segundos. 
a O dispositivo de menor BID vence a eleição. 


Quando a rede inicializa, todos os switches anunciam uma mistura caótica de BPDUs, e ime- 
diatamente começam a aplicar a sequência de 5 passos do processo de decisão para escolha 
dos melhores caminhos. Os switches precisam eleger uma única “root bridge”, sendo que 
vence o switch com o menor BID. Diversos autores referem-se ao termo “highest priority” 
como o valor de menor BID, pois quanto menor o valor do campo “bridge priority” no BID, 


maior é a probabilidade do switch emissor ser eleito como “root bridge”. 


No início, todas as bridges informam ser a “root bridge”, colocando seus BIDs no campo “Root 
ID” da BPDU. No exemplo da Figura 5.28, quando todos os switches perceberem que o switch 
“Acesso 2” tem o menor BID, todos concordarão que o switch “Acesso 2” é a “root bridge”. 
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32768-000f.2490.1380 


Núcleo 
32768-000b.fd13.9080 aie. 32768-000b.fd13.cd80 
Distribuição 1 Go ane Distribuição 2 
< m~ Eon Goa ae 
a -> Fa0/2 Fa0/1 =: ~= 
eA b Fa0/1 G0/1 `... aa 
G0/2 Fa0/2 
G0/2 Fa0/1 
+ Es 1, 601 Fa0/2@ cn 
~~ ~~ Root Bridge 
a CRIA Fa0/3 : a 
PRN Sorea Figura 5.28 
Acesso 1 Acesso 2 Bn 
Eleição da 
32768-000b.befa.eec0 32768-0009.7c0b.e7c0 “root bridge”. 
Tamanho (Bytes) Campo 
2 : Protocol ID 
1 : Version 
1 : Messagem type 
1 : Flags 
8 : Root ID Quem é a raiz? 
4 : Root Path Cost Qual a distância para a raiz? 
8 : Bridge ID Qual o BID da bridge que enviou este BDPU? 
2 : Port ID De qual porta da bridge partiu este BDPU? 
2 : Message age 
2 : Max age 
2 : Hello time 
2 Forward delay Figura 5.29 


Layout da BPDU. 


Exemplo de BPDU: 

BPDU 

802.3 Header 
Destination: 01:80:C2:00:00:00 Mcast 802.1d Bridge group 
Source: 00:09:7C:0B:E7:CO0 
LLC Length: 38 

802.2 Logical Link Control (LLC) Header 
Dest. SAP: 0x42 802.1 Bridge Spanning Tree 


Source SAP: 0x42 802.1 Bridge Spanning Tree 





Command: 0x03 Unnumbered Informatio 
802.1 - Bridge Spanning Tree 
Protocol Identifier: O 


Protocol Version ID: O 


Message Type: O Configuration Message 
Flags: %00000000 
Root Priority/ID: 0x8000/ 00:09:7C:0B:E7:CO 


Cost Of Path To Root: 0x00000000 (0) 


Bridge Priority/ID: 0x8000/ 00:09:7C:0B:E7:C0 


Port Priority/ID: 0x80/ 0x1D 

Message Age: 0/256 seconds (exactly O seconds) 
Maximum Age: 5120/256 seconds (exactly 20 seconds) 
Hello Time: 512/256 seconds (exactly 2 seconds) 
Forward Delay: 3840/256 seconds (exactly 15 seconds) 


a O switch com o menor BID se torna a “root bridge”. 


a A“root bridge” pode ser escolhida reduzindo a prioridade no switch, abaixo do 
default de 32768. 


a Existem dois modos de baixar a prioridade de um switch para fazê-lo a “root bridge”: 
Switch-2(config)#spanning-tree vlan 1 root primary 

ou 

Switch-2(config)#spanning-tree vlan 1 priority new-value 


O comando spanning-tree vlan 1 root primary baixa automaticamente a prioridade do switch 


para torná-lo a “root bridge”. 


O comando spanning-tree vian 1 priority 4096 baixa a prioridade do switch de 32768 para 4096, 
tornando-o a “root bridge”, caso a menor prioridade configurada nos switches seja 4096. 
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32768-000f.2490.1380 
Núcleo 


32768-000b.fd13.9080 Ss 32768-000b.fd13.cd80 
Distribuição Distribuição 2 


BPDU 
Cost=0+19=19 P 


J BPDU 
1 Cost=0+19=19 


Fa0/2 
19] 0 
Fa0/ 









Root Bridge 





Acesso 2 
32768-000b.befa.eec0 32768-0009.7c0b.e7c0 


Acesso 1 


9. A“root bridge” "Acesso 2” envia BPDUs contendo o campo “Root Path Cost” = 0, sinali- Figura 5.30 


zando que o custo até a “root bridge” é nulo. Eleição de 


“root ports”. 
10. Os switches “Acesso 1”, “Distribuição 1” e “Distribuição 2” recebem estas BPDUs e adi- 


cionam o custo da interface Fast Ethernet, denominado “Path Cost”, ao “Root Path Cost” 
contido na BPDU recebida. Desta forma, cada switch calcula o valor do seu respectivo 
campo “Root Path Cost”: 0 + 19 = 19 (usado internamente e propagado em BPDUs para 
outros switches, conforme ilustra a Figura 5.31). 


o Path Cost - valor atribuído a cada porta, sendo adicionado às BPDUs recebidas naquela 
porta para calcular o “Root Path Cost”. 
o Root Path Cost - custo acumulado do caminho para a “root bridge”, sendo um valor 


transmitido em BPDUs para outros switches, calculado ao adicionar o “Path Cost” asso- 


ciado à porta receptora da BPDU ao valor do “Root Path Cost” contido na BPDU. 


32768-000f.2490.1380 Figura 5.31 


Núcleo Cálculo do custo 


+ are ee das “root ports”. 


32768-000b.fd13.9080 ata 32768-000b.fd13.cd80 





Distribuição Distribuição 2 
BPDU 60/24 BPDU 
Cost=4+19=23 P Fa0/1 —| Cost=4+19=23 

G0/2.- GO aes 
BPDU Fa0/2 
Cost=19 || 19 0 

Fa0/1 
G02 Fa0/2 oo è 


30º o rá 
E Gr 0 = eo eee 
in. É a; 


Acesso 1 Acesso 2 
32768-000b.befa.eecO 32768-0009.7c0b.e7c0 


a Os switches agora enviam BPDUs com seus respectivos “Root Path Cost” em todas as 


outras interfaces. 


11. O switch “Acesso 1” usa este valor de 19 internamente e envia BPDUs em todas as outras 


portas sinalizando no campo “Root Path Cost” este valor. 


12. Os switches "Distribuição 1” e “Distribuição 2” recebem as BPDUs de “Acesso 1” e adi- 
cionam o custo de suas interfaces Gigabit Ethernet (Path Cost), cujo valor é 4, ao “Root 
Path Cost” contido na BPDU recebida, resultando num “Root Path Cost” de 23. 


Entretanto, ambos os switches já têm um “Root Path Cost” interno de 19 recebido em outra 
interface. Desta forma, como ilustrado na Figura 5.32, para encontrar os melhores cami- 
nhos, “Distribuição 1” e “Distribuição 2” usam o menor “Root Path Cost” identificado (19) 


quando enviam as suas BPDUs para outros switches. 


Em caso de caminhos de custos iguais, este processo usa a sequência de 5 critérios de decisão 
para eleição da “root port”, que representa a porta de saída com menor custo até a “root bridge”. 


32768-000f.2490.1380 
Núcleo 







BPDU 


32768-000b.fd13.9080 Cost=4+19=23 


Distribuição 1 


BPDU 
W| Cost=19 


32768-000b.fd13.cd80 


Distribuição 


G0/1 G0/2 










G0/2 =| BPDU 
Fa0/1 | Cost=19+19=38 
23° 
19 
0 


0 Ú EN Root Bridge 
O Fa03: mi $ 
> 


Acesso 1 Acesso 2 
32768-000b.befa.eecO 32768-0009.7c0b.e7c0 


Figura 5.32 13, O switch “Distribuição 1” agora envia BPDUs com seu “Root Path Cost” de valor 19 em 
Cálculo do custo 


das “root ports” 
(cont). 
® Novamente, “STP costs” são incrementados quando as BPDUs são recebidas numa 


todas as outras interfaces. 


porta, e ndo quando sdo enviadas para fora de uma porta. 
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32768-000f.2490.1380 Figura 5.33 


Núcleo Cálculo do custo 


< ee, das “root ports” 
19+4=23 ~~ 19+4=23 (cont). 

32768-000b.fd13.9080 DA i, > 

Distribuição vs 

q: Gon 19+19=38 19+19=38 Gogo UI 

~ Fa0/2 Fa0/1 ~~ 


“19 





19+4=23 0 
G0/2 19+4=23 Fa0/1 


& E Eca e GO/1 Fa0/2 a no eet 
~~ bb (E ~R t Brid 
Emei ds Fa0/1 O Fa0/3 = hoe adiada 


Acesso 1 Acesso 2 
32768-000b.befa.eecO 32768-0009.7c0b.e7c0 


Como resultado, a Figura 5.33 mostra o menor custo até a “root bridge” via cada uma das 
interfaces dos switches. Como pode ser observado na figura, este custo do “Root Path Cost” 
de cada interface é calculado somando o melhor “Root Path Cost” recebido nas BPDUs via a 


interface e o “Path Cost” da própria interface. 


Root Path Cost da interface = BPDU Root Path Cost + Path Cost da interface (após a “melhor” 
BPDU ser recebida na porta proveniente do switch vizinho). Este é o custo para alcançar a 


“root bridge” a partir desta interface em direção ao switch vizinho. 
Eleição de “root ports” 


a Cada“non-root bridge” deve selecionar uma “root port”. 
o Uma “root port” é a porta mais “próxima” da “root bridge”. 


a Bridges usam custo (cost) para determinar proximidade; pela perspectiva do switch: 
Qual é meu custo para a “root bridge”? 


a Posteriormente analisaremos “designated ports” pela perspectiva do segmento. 


No exemplo da Figura 5.34, o switch “Distribuição 1" avalia o custo do caminho até a “root 
bridge” via cada uma de suas interfaces, concluindo que a interface Fast Ethernet de custo 


19 representa o melhor caminho e, portanto, esta interface é selecionada como “root port”. 


Figura 5.34 32768-000f.2490.1380 
Decisão do switch Núcleo 
“Distribution 1”. 





Por aqui 







custa 27 Por aqui 32768-000b.fd13.cd80 
custa 38 G0/2 
w r 2 
PAP 
con 38 => 38 G0/2 















Por aqui E 
custa 23 Por aA 
só 19! o4 
E ou Aqui é o melhor Fa0/2 Gs 





caminho para 
a root bridge 






O <> Root Bridge 
0: S 


Aes 1 Acesso 2 
32768-000b.befa.eecO 32768-0009.7c0b.e7c0 






Decisão dos outros switches 


Figura 5.35 
Resultado final 
do cálculo das 

“root ports”, 


32768-000f.2490.1380 
Núcleo 


Root Port + 
©) “mia 23 
32768-000b.fd13.9080 > 32768-000b.fd13.cd80 


Ro 1 Distribuição 2 

+ ee GAJ 2> ' P N 
Go/1 38 38 02%: 

“3 ~ > 


Fa0/1 =: 
Root Port E age 





Root Port 
« 23 0 
on L3, . con Fa0/2 ql 
0 a 
< wom Port E =, Root Bridge 
x Ze 0 Fa0/3: 5. ~$ 
oo 1 Acesso 2 


32768-000b.befa.eec0 


32768-0009.7c0b.e7c0 


Em relação à eleição de “root ports”, os switches “Distribution 2” e “Acesso 1” realizam um 
procedimento similar ao “Distribution 1”, também selecionando como “root port” as 
interfaces com “Root Path Cost” de 19. No entanto, diferentemente, o switch “Core” tem duas 
interfaces com valores de “Root Path Cost” iguais. Neste caso devemos analisar o processo 
de decisão de 5 critérios. 

o 1- Menor BID (Lowest BID) 

a 2- Menor custo do caminho para a “root bridge” (Lowest Path Cost to Root Bridge) 

a 3- Menor BID do enviador (Lowest Sender BID) 


a 4-Menor prioridade de porta (Lowest Port Priority) 


a 5- Menor BID de porta (Lowest Port ID) 
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Na perspectiva do switch “Core”, o switch “Distribution 1” tem um BID de origem menor 
que “Distribution 2”. Portanto, com base no terceiro critério, o switch “Core” escolhe a 
interface G0/1 como “root port”, definindo um caminho até a “root bridge” que passa pelo 
switch “Distribution 1”. 


Eleição de “designated ports” 


CJ 
A prevenção de loop do STP se torna evidente durante a eleição das “designated ports”. 
Uma “designated port” funciona como a única porta conectada ao segmento que envia e 


recebe tráfego entre o segmento e a “root bridge”. 


Cada segmento numa rede de bridges tem uma “designated port”, escolhida com base 
no “Root Path Cost” de seus respectivos switches até a “root bridge”. O switch contendo 
a “designated port” é denominado “designated bridge” para aquele segmento. 


Sob a perspectiva de um dispositivo neste segmento: Para qual switch devo ir para chegar 


à root bridge? 


Obviamente, o segmento não tem a capacidade de calcular o “Root Path Cost” e tomar a 
decisão, de modo que a perspectiva e a decisão são dos switches no segmento. Para loca- 
lizar as “designated ports”, é necessário verificar cada segmento. 
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Qual é o melhor caminho 
para a root bridge, 

19 via “Distribution 1” 
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Qual é o melhor caminho 
para a root bridge, 
19 via “Access 1” ou 


Ovia “Access 2”? Figura 5.36 


Eleição das 
“designated ports”. 


1. Uma “designated port” é eleita para cada segmento. Ela é a única porta conectada ao 
segmento que envia/recebe tráfego entre o segmento e a “root bridge”, isto é, a melhor 
porta em direção à “root bridge”. 


2. Para qual switch devo ir para chegar à “root bridge”? 


Eu decidirei através do “Root Path Cost” anunciado por cada switch. 


O “Root Path Cost” anunciado é o custo indicado na BPDU pelo switch, isto é, o custo para 


chegar a “root bridge” passando por ele. 


a No segmento entre “Acesso 2” e “Acesso 1”, "Acesso 2” tem “Root Path Cost” = 0 (afinal, ele 
é a “root bridge”) e “Acesso 1” tem “Root Path Cost = 19”. Já que “Acesso 2" tem “Root Path 


Cost” menor, sua porta no segmento se torna a “designated port” para o segmento. 


a O mesmo ocorre no segmento entre “Acesso 2” e “Distribution 1”, bem como entre 
“Acesso 2" e “Distribution 2”. Já que “Acesso 2” tem o menor “Root Path Cost”, suas 


portas também se tornam “designated ports” para estes segmentos. 


a No segmento entre “Distribution 1” e “Acesso 1”, os switches possuem “Root Path Cost” 
com valores iguais a 19. Usando o menor BID de origem (os dois primeiros passos são 


iguais), a porta de “Acesso 1” se torna o melhor caminho e a “designated port”. 
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Figura 5.37 o No segmento entre “Distribution 1º e “Distribution 2”, os switches também possuem 
Topologia “Root Path Cost” com valores iguais a 19. Novamente, usando o menor BID de origem, a 


loop free final. ia RS , , 
porta de “Distribution 1” se torna o melhor caminho e a “designated port”. 


o Deforma similar, no segmento entre “Acesso 1” e “Distribution 2”, os switches possuem 
“Root Path Cost” com valores iguais a 19. Assim, usando o menor BID de origem, a porta 
de “Acesso 1” se torna o melhor caminho e a “designated port”. 


a Nos segmentos que conectam o switch “Core”, os switches “Distribution 1” e “Distribution 
2" possuem “Root Path Cost” com valores menores. Logo, as portas de “Distribution 1” e 
“Distribution 2” se tornam os melhores caminhos e as “designated ports”. 


o Uma vez concluída a eleição de “root ports” e “designated ports”, todas as outras portas 


que não são “root ports” ou “designated ports” se tornam “non-designated ports”. 
a “Non-designated ports” são colocadas em blocking mode. Esta é a parte de prevenção de 


loop do STP, conforme pode ser observado na Figura 5.37. 


É importante destacar que as “designated ports” nunca são bloqueadas, pois seus seg- 
mentos podem ter repetidores ou hubs conectados, permitindo que os dispositivos conec- 
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Estados de porta — Spanning Tree 


Estado Objetivo 

Forwarding T : Enviando/recebendo dados de usuário. 

Learning T : Construindo a tabela de bridges (switches). 

Listening T : Construindo a topologia “ativa”. 

Blocking T ! Recebe BPDUs somente. 
: Figura 5.38 

Disabled T : Administrativamente “down”. Estados de 
: porta STP. 


ao Disabled - a porta está administrativamente desativada (shutdown). 


a Blocking -todas as portas começam no estado “blocking” a fim de evitar que a bridge 
crie um loop. Neste estado, a porta processa BPDUs, mas não envia ou recebe dados dos 
usuários. A porta passa do estado “blocking” para o estado “listening” quando ganha a 
eleição para “root port” ou “designated port. Caso contrário, se torna uma “non-desig- 
nated port” e permanece no estado “blocking”. Assim, uma porta permanece ou volta ao 
estado “blocking” se o Spanning Tree determina que existe um caminho melhor para a 
“root bridge”. Pode levar até 20 segundos para que uma porta saia deste estado (tempori- 
zador denominado “max age”). 


a Listening - as portas tentam aprender se existem outros caminhos para a “root bridge”, 
servindo como um estado intermediário para estabilizar os estados nas portas dos 
diversos switches. Neste estado, a porta processa BPDUs, mas ainda não envia ou recebe 
dados dos usuários. Também escuta por um período de tempo chamado de "forward 
delay” (default de 15 segundos). 


ao Learning - o estado “learning” é muito similar ao estado “listening”, exceto pelo fato de 
que a porta pode adicionar informação aprendida na sua tabela de endereços. Ainda 
não é permitido enviar/receber dados dos usuários. Aprende por um período chamado 
“forward delay” (default de 15 segundos). 


a Forwarding - a porta pode enviar e receber dados dos usuários. Uma porta é colocada 
no estado “forwarding” se: não existem links redundantes ou se é determinado que ela 
possui o melhor caminho para a “root bridge”. 


Temporizadores STP 


Spanning Tree faz com que cada porta passe por vários estados diferentes, sequencialmente. 


Blocking (detectada perda de BPDU) 
(max age = 20 sec) 


Listening Blocking (vai para listening 
(forward delay = 15 sec) depois da decisão se é uma Enlace ativado 
root port ou uma designated port) 


i Tempo máximo para passar do estado de Blocking para Forwarding: 
Learning 20 seg + 15 seg + 15 seg = 50 segundos 





(forward delay = 15 sec) 





Figura 5.39 o Hello time - tempo decorrido entre envios consecutivos de BPDUs de configuração 


Temporizadores STP. (2 segundos); 


o Forward delay - duração do período de escuta e aprendizado, adotado nos estados 


“listening” e “learning” (15 segundos); 


o Max age -tempo de armazenamento das BPDUs (20 segundos). 


Rapid Spanning Tree Protocol (RSTP) 


a O problema imediato do STP é a convergência. 

o Dependendo do tipo de falha, pode levar de 30 a 50 segundos para a rede convergir. 

a RSTP auxilia a questão da convergência (problemática no STP). 

a RSTP é proativo e não necessita dos temporizadores 802.1D. 

a RSTP (802.1w) substitui 802.1D, mas mantém a compatibilidade. 

O formato das RSTP BPDUs é o mesmo formato das IEEE 802.1D BPDUs, exceto pelo campo 
“Version”, que é configurado para 2 (para indicar RSTP). O RSTP Spanning Tree Algorithm 


(STA) elege uma “root bridge” exatamente da mesma maneira que o 802.1D. 


Diferenças importantes fazem do RSTP o protocolo preferido na prevenção de loops em 
redes baseadas em switches. STP e RSTP também têm algumas diferenças nas designações 
das portas: 

o RSTP tem “alternate ports” e “backup ports”. 

a Portas que não participam do Spanning Tree são chamadas de portas de borda (edge ports). 


ao As“edge ports” se tornam “non-edge ports” imediatamente após receberem uma BPDU, 


passando a participar do Spanning Tree. 
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RSTP versus STP 


Ea 
RSTP é baseado no padrão IEEE 802.1w e requer conexões full-duplex ponto-a-ponto 


entre os switches vizinhos para alcançar convergência mais rápida. Existem numerosas 
diferenças entre RSTP e STP. 


Half-duplex denota meio compartilhado e múltiplos dispositivos. Como resultado, RSTP 


não converge rapidamente em um ambiente half-duplex. 


RSTP foi definido no padrão IEEE 802.1w e desenvolvido com o objetivo de minimizar o 


tempo de convergência do STP que, como vimos, pode chegar a 50 segundos. Esse tempo, 


considerando a velocidade de uma rede local (100 Mbps, 1 Gbps), é uma “eternidade”. 


O RSTP exige que todas as portas dos switches operem em full-duplex para maior eficiência. 


Os estados das portas no protocolo RSTP são diferentes dos estados no protocolo STP, o que 


permite uma convergência mais rápida, em caso de mudança de topologia da rede (quebra de 


enlace, falha de equipamento etc.). A seguir descreveremos em mais detalhes o RSTP. 


Estados de portas RSTP 


Discarding (descartando). 
Learning (aprendendo). 
Forwarding (redirecionando). 


Discarding - pode ser visto tanto em uma topologia ativa e estável, quanto durante a 
sincronização e alterações em uma topologia. Não realiza o redirecionamento de pacotes 


de dados, evitando consequentemente a formação de loops na camada 2. 


Learning - pode ser visto tanto numa topologia ativa e estável, quanto durante a sincro- 
nização e alterações em uma topologia. Aceita pacotes de dados para preencher a tabela 


MAC, em um esforço para limitar o fluxo de pacotes unicast desconhecidos. 


Forwarding - este estado é visto apenas em topologia estável. As portas no estado “redi- 
recionando” determinam a topologia ativa da rede. 


Portas RSTP 


\ 


Root ports. 
Designated ports. 
Alternate port. 


Backup port. 


Root Ports 





R 


Alternate Port 





Figura 5.40 —> 


Funções das 
portas RSTP. 


NE 


Root Port 


Designated Ports 





a 


Backup Port 





2 ——— A 


Como no STP, a porta raiz é a porta escolhida como caminho para a “root bridge”, em uma 
“non-root bridge”. Só poderá haver uma porta raiz em cada switch. A porta raiz assume o 


estado redirecionando em uma topologia ativa e estável. 
Designated Port 


Como no STP, cada segmento tem, pelo menos, uma porta como porta designada. Em uma 

topologia ativa e estável, o switch com a porta designada recebe pacotes no segmento desti- 
nado para a “root bridge”. Só poderá haver uma porta designada por segmento, que assume 
o estado, redirecionando. Todos os switches em um dado segmento ouvem todos os BPDUs 


e determinam o switch que será designado para um segmento em particular. 
Alternative Port 


Equivalente à “non-designated port” no STP, a porta “alternativa” é a porta que oferece um 
caminho alternativo em direção à ponte raiz. Assume o estado descartando em uma topo- 
logia ativa e estável. Uma porta alternativa está presente em switches não designados, e faz 


a transição para uma porta designada se o caminho designado falhar. 
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Backup Port 


A porta “backup” é uma porta adicional no switch designado com um link redundante para 
o segmento ao qual o switch é designado. A porta “backup” tem um maior “port ID” do que 
a porta designada no switch designado. A porta “backup” assume o estado descartando em 


uma topologia ativa e estável. 


Protocolo PPP 


O protocolo PPP é um protocolo criado para operar na camada de enlace de dados da 
arquitetura TCP/IP, com o objetivo de encapsular datagramas IP em enlaces seriais de longa 


distância dedicados ou comutados, ou seja, em redes WAN. 


Camada de enlace da WAN 


a High-Level Data Link Control (HDLC). 

o Frame Relay. 

o Link Access Procedure Frame (LAPF). 

a Link Access Procedure Balanced (LAPB). 

o Link Access Procedure D-channel (LAPD). 

a Point-to-Point Protocol (PPP). 

a Synchronous Data Link Control Protocol (SDLC). 


o Serial Line Internet Protocol (SLIP). 


E CSU/DSU CSU/DSU a a 
3 4 E PE modem s 4 v Figura 5.41 
“O | | o Camada de enlace 


redes WAN. 


O PPP não é o único protocolo projetado para operar na camada de enlace de redes WAN. 


Podem ser usados, dependendo das aplicações, os seguintes protocolos: 


a HDLC (High-Level Data Link Control) é o protocolo de enlace padrão ISO para redes de 
dados baseadas no protocolo X-25. Pode não haver compatibilidade entre fabricantes dife- 
rentes, dependendo das opções feitas pelo fabricante na implementação; suporta tanto 


configurações ponto-a-ponto como multiponto, com perda mínima de performance. 


o Frame Relay utiliza facilidades digitais de alta qualidade; usa quadros simplificados sem 
mecanismos de correção de erros, o que possibilita o envio de informação de camada de 


enlace muito mais rapidamente do que qualquer outro protocolo WAN. 


o LAPB (Link Access Procedure Balanced) é um protocolo de enlace derivado do HDLC e usado 
pelo X.25; tem uma capacidade de verificação de erros bastante completa. O protocolo X-25 
foi o primeiro protocolo a ser usado nas redes de dados das operadoras de telecomunica- 
ções. Devido a suas limitações de velocidade (utilizado em velocidades de até 64 kps), seu 
uso está em declínio, podendo ser encontrado ainda na RENPAC da Embratel. 


a LAPD (Link Access Procedure on the D-channel) é o protocolo de enlace WAN usado para 
transportar informações de controle e sinalização nos procedimentos de estabeleci- 
mento de chamadas (call setup) em canais D-ISDN; os canais B-ISDN fazem a transmissão 
dos dados. A tecnologia ISDN (Integrated Services Digital Network) ou RDSI (Rede Digital 


de Serviços Integrada) foi criada para operar serviços de dados digitais em linhas telefô- 


nicas, mas foi tornada obsoleta pela tecnologia xDSL. 


o LAPF (Link Access Procedure for Frame Mode Bearer Services) é o protocolo de enlace 
WAN usado com as tecnologias de Frame Relay. Representa uma melhoria do LAPD, 


incluindo facilidades de controle de congestionamento. 


a SDLC (Synchronous Data Link Control) é um protocolo de enlace WAN projetado pela IBM 
para a arquitetura Systems Network Architecture (SNA); tem sido substituído pelo proto- 
colo HDLC, que é mais versátil. O SDLC tornou obsoleto o protocolo BSC-3, muito usado 
pela IBM nas décadas de 60 e 70. 


ao PPP (Point-to-Point Protocol) é descrito pelo RFC 1661 e desenvolvido pelo IETF; 
contém um campo de protocolo para identificar o protocolo de camada de rede que 


está sendo encapsulado. 


o SLIP (Serial Line Interface Protocol) é um protocolo de enlace WAN muito popular nos pri- 


mórdios da internet, usado para encapsulamento de pacotes IP; atualmente está sendo 


Figura 5.42 Roi a , En o 
visão geral do pro- substituído pelo protocolo PPP, que é mais seguro e, ao contrário do SLIP, tem a facilidade 
tocolo PPP. de identificar o protocolo de camada de rede. 


Point-to-Point Protocol (PPP) 


Encapsulamento de 
múltiplos protocolos 
usando NCPs em PPP 










to Encapsulamento PPP SAN. 
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Link setup e controle 
usando LCP em PPP 





Flag ` ° Protocolo Dados Flag 
01111110 01111110 





1 1 1 2 Tamanho variavel 20u4 
byte byte byte bytes (Padrão: máximo 1500 bytes) bytes E 


Método de encapsular datagramas em linhas seriais com três componentes: 

a LCP (Link Control Protocol) provê um método para estabelecer, configurar e testar a 
conexão de dados. 

a NCP (Network Control Protocols) estabelecem e configuram diferentes protocolos de rede. 


o IPCP (Internet Protocol Control Protocol) é o NCP específico para o protocolo IP. 


X Capítulo 5 - Protocolos de enlace 


205 


SX Arquitetura e Protocolos de Rede TCP-IP 


206 


Diversos RFCs especificam aspectos do PPP. O RFC 1661 é a especificação mais importante para a 
maioria das operações do PPP (NCP e LCP). PPP pode transportar pacotes provenientes de vários 
protocolos de camada superior através de componentes do tipo Network Control Protocol (NCP). 
Ainda controla a configuração de diversas opções de enlace usando o componente Link 

Control Protocol (LCP) e a transmissão de datagramas sobre enlaces seriais ponto-a-ponto. 


Comparação HDLC e PPP 


possui um campo para indicar o protocolo transportado. A Cisco oferece uma versão | 


HDLC padrão ISO não suporta múltiplos protocolos num mesmo enlace, já que não 


proprietária do HDLC que usa um campo Type como campo de protocolo. 


O protocolo PPP usa o mesmo tipo de quadro do protocolo HDLC padrão ISO, com a diferença 
de que o HDLC suporta apenas ambientes de um único protocolo de rede, e o PPP tem um 


campo para identificação do protocolo de rede cujos dados foram encapsulados no quadro PPP. 





Pacote HDLC ISO Figura 5.43 
Comparação entre 
Data (payload) HDLC e PPP. 
1 1 1-2 1500 20u4 1 
byte byte byte bytes bytes byte 





Pacote PPP 
Flag Protocol Data (payload) 
1 1 1 1-2 1500 2 (ou 4) 1 
byte byte byte bytes bytes bytes byte 


O HDLC (da Cisco) tem um campo proprietario Type usado para dar suporte a ambientes com 
múltiplos protocolos. O HDLC é o protocolo padrão de camada 2 para interfaces seriais de 
roteador Cisco. 


Mapeamento PPP com modelo OSI 


Vá 

PPP é um protocolo de enlace de dados com serviços de camada de rede. an 
A Figura 5.44 mapeia os elementos PPP em relação ao modelo OSI. Usando opções de LCP 
do PPP, um administrador pode prover acesso seguro e realizar uma transferência confiável 


de dados. O PPP transporta vários protocolos de camada de rede usando diferentes NCPs. 


Figura 5.44 
Mapeamento PPP 
com modelo OSI. 
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Network Control Protocol 
PPP 


Autenticação, outras opções Camada de enlace 
Link Control Protocol de dados 


Meio físico síncrono ou assíncrono Camada física 


Fases PPP 


Estabelecimento e configuração do enlace (LCPs). 

m Autenticação e compressão - opcionais (LCPs). 

Teste da qualidade do enlace - opcional (LCPs). 
Configuração dos protocolos da camada de rede (NCPs). 


Término do enlace (LCPs). 


O PPP está dividido em 4 fases: 


Estabelecimento e configuração do enlace - antes que quaisquer pacotes de camada de 
rede sejam trocados, cada dispositivo PPP deve primeiramente enviar pacotes LCP para 
abrir a conexão e negociar os parâmetros de configuração do enlace. Quadros LCP contêm 
um campo de opção de configuração que permite aos dispositivos negociarem o uso de 
opções, tais como Maximum Transmission Unit (MTU), a compressão de certos campos 
PPP e o protocolo de autenticação de enlace. Depois que o enlace está estabelecido e o 
protocolo de autenticação negociado, o dispositivo pode ser autenticado. PPP suporta 
dois protocolos de autenticação: PAP e CHAP. Ambos estão detalhados no RFC 1334 (PPP 
Authentication Protocols). Entretanto, o RFC 1994 (PPP Challenge Handshake Authentica- 
tion Protocol) torna obsoleto o RFC 1334. Se uma opção de configuração de autenticação 


não for incluída no pacote LCP, o valor default é assumido (isto é, sem autenticação). 


Teste da qualidade do enlace - opcionalmente, o LCP pode testar o enlace para verificar 
se a qualidade é boa o suficiente para suportar a ativação e operação dos protocolos da 


camada de rede. 


Configuração dos protocolos de rede - nesta fase opcional, os dispositivos PPP enviam 
pacotes NCP para escolher e configurar um ou mais protocolos da camada de rede, como 
o protocolo IP. Uma vez escolhidos e configurados, pacotes de cada protocolo da camada 
de rede podem ser enviados no enlace. É importante ressaltar que existem diferentes 

protocolos NCP para diferentes protocolos da camada de rede. Por exemplo, o protocolo 


IPCP configura o protocolo IP, enquanto IPXCP configura o protocolo IPX. 


Término do enlace - LCP pode terminar a conexão a qualquer instante por solicitação do 
usuário ou por um evento físico, como perda de portadora. Se o LCP fechar o enlace, infor- 


mará os protocolos da camada de rede para que tomem as providências pertinentes. 
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Opções LCP 


PAP ou CHAP 


Autenticação ~ ra Ste 


Compressão 





Multilink 
Bundle 

Figura 5.45 

Opções de LCP. 
Opção LCP Protocolo Como opera 
Autenticação : PAP/CHAP : Precisa de uma senha/realiza desafio Challenge Handshake. 
Compressão : Stacker ou Predictor ; Comprime os dados na origem e reproduz no destino. 
Detecção de erros : Magic Number ; Permite detectar laços (loops) nos enlaces PPP. 
Multi links : Multilink Protocol (MP) : Permite realizar balanceamento de carga (load balancing). 


A compressão PPP é negociada pelo Compression Control Protocol (CCP), definido no RFC 
1962. O RFC 1548 descreve e detalha as opções PPP aprovadas pela Internet Engineering 
Task Force (IETF). O RFC 1717 define o Multilink Protocol. O RFC 1990 define o PPP Multilink 
Protocol (MP) e torna obsoleto o RFC 1717. 


Para aperfeiçoar a segurança e flexibilidade das conexões, o “Cisco IOS Release 11.1” oferece 
a facilidade de callback sobre PPP. Com esta opção LCP, um roteador Cisco pode agir como 


um cliente ou como um servidor para callback. Esta opção é descrita no RFC 1570. 


Fase de autenticação 


Depois do enlace estabelecido e o protocolo de autenticação decidido, o dispositivo 
pode ser autenticado. Se utilizada, a autenticação ocorre antes do início da fase de con- 
figuração dos protocolos de rede (suporta autenticação PAP ou CHAP). Após esta fase, o 
LCP também permite um teste opcional de determinação da qualidade do enlace. 


Figura 5.46 
Fase de autenti- 
cação do PPP. 


Autenticação PAP ou CHAP 


A fase de autenticação do protocolo PPP é opcional e, se utilizada, ocorre antes da fase de 
configuração dos protocolos da camada de rede. Podem ser usados os métodos PAP ou 


CHAP, sendo o segundo o mais utilizado, por ser mais seguro. 


Servidor de autenticação remoto 


Autenticação a partir de um cadastro local de usuários (username:password). 
a Password Authentication Protocol (PAP). 

a Challenge Handshake Authentication Protocol (CHAP). 

Servidor de autenticação remoto: 


ao Terminal Access Controller Access Control System Plus (TACACS+). 





a Remote Access Dial-In User Service (RADIUS). 


Os protocolos TACACS+ e RADIUS são os mais usados em servidores de autenticação. 


Os provedores, de maneira geral, preferem este último. 


Autenticação PAP 


a Senhas enviadas em claro. 
a Dispositivo possui controle das tentativas. 


a Pouco segura, pois a senha passa sem criptografia na rede - o usuário remoto controla 


e comanda o processo. 


PAP provê um método simples para um nó remoto estabelecer sua identidade usando um 
two-way handshake, sendo executado no momento do estabelecimento inicial do enlace. 
Basicamente, como mostrado na Figura 5.47, o nó a ser autenticado envia o nome do host e 
a senha, que são validados pelo nó na outra extremidade do enlace. PAP não é um protocolo 
de autenticação forte, uma vez que não inclui criptografia, ou seja, o nome do host e a senha 


são enviados sem qualquer proteção. 
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Remote Router PAP Central-Site Router 
(SantaCruz) 2-Way Handshake (HQ) 


santacruz, 
boardwalk 





Aprova/Rejeita 


Hostname: santacruz 
Password: boardwalk 


Hostname: santacruz 
Password: boardwalk 


Figura 5.47 
Autenticação PAP. 





Autenticação CHAP 
Usa um segredo conhecido apenas pelo autenticador e pelo dispositivo, sendo mais 
segura que a autenticação PAP. J 


CHAP também é executado no momento inicial de estabelecimento do enlace, e pode ser 
repetido a qualquer tempo após o enlace estar estabelecido: as transações no CHAP só 
ocorrem após o enlace estar estabelecido. 


O servidor de autenticação não solicita uma senha durante o procedimento de autenticação. 
Ao invés disso, usa o algoritmo Message Digest 5 (MD5) para calcular um hash a partir de um 
código, palavra ou pequeno texto (chamado desafio) e uma senha compartilhada entre os 
dispositivos conectados ao enlace PPP. 


O servidor de autenticação envia o desafio para o dispositivo remoto; este calcula o hash 
MDS a partir do desafio e da sua senha compartilhada. Em seguida, envia o hash para o 
servidor de autenticação. Se o hash recebido “bater” com o hash calculado pelo próprio 


servidor de autenticação, ele aceita a conexão. CHAP está detalhado no RFC 1334. 
A Figura 5.48 mostra uma autenticação CHAP, o protocolo de autenticação preferido e reco- 


mendado para enlaces PPP. 


Remote Router CHAP Central-Site Router 
(SantaCruz) 3-Way Handshake (HQ) 


q 


Aprova/Rejeita 


Hostname: santacruz Hostname: santacruz 


: Figura 5.48 
Password: boardwalk SS ca Password: boardwalk Autenticação CHAP. 





Figura 5.49 
Passos de uma 
autenticação CHAP. 


Figura 5.50 
Configuração PPP 
Multilink (MLP). 


A Figura 5.49 resume todos os passos de uma autenticação CHAP, desde o início da conexão PPP. 


Usuário remoto: Peixoto Servidor de acesso 





Inicia PPP 


Usa CHAP Cadastro local 


aS de usuarios 


Requisita “desafio” 


= 


“Desafio” 


Informa nome e senha 
quando solicitado 


Usuário: peixoto 


Resposta Senha: teste 


= 


Aceita ou rejeita conexão 





Configurando PPP Multilink (MLP) 


Em alguns ambientes, pode ser necessário unir vários enlaces seriais para que eles 


operem como um único enlace serial com a banda total agregada. 


Multilink PPP permite balanceamento de carga nas interfaces do roteador onde é configu- 


rado. Conforme especificado na RFC 1717, a fragmentação e sequenciamento de pacotes 


Router(config)# interface serial 0/0 
Router(config-if)# encapsulation ppp 
Router(config-if)# ppp multilink 
Router(config-if)# ppp multilink group 1 


Router(config)# interface serial 0/1 
Router(config-if)# encapsulation ppp 
Router(config-if)# ppp multilink 
Router(config-if)# ppp multilink group 1 


Router(config)# interface multilink 1 

Router(config-if)# ip address 192.168.1.1 255.255.255.252 
Router(config-if)# ppp multilink 

Router(config-if)# ppp multilink group 1 








dividem a carga e provocam o envio dos fragmentos nos circuitos PPP paralelos. Em alguns 


casos, este conjunto de dutos Multilink PPP funciona como um único enlace lógico, otimi- 


zando banda e reduzindo a latência entre os roteadores pareados. 





SantaCruz HQ 
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Digital Subscriber Line (DSL) 


Embora considerada uma solução fim-a-fim, DSL opera somente no loop local entre o 
equipamento do usuário (CPE) e o multiplexador de acesso DSL (DSLAM). Um DSLAM é um 
dispositivo no escritório central (CO), usado para terminar as conexões DSL de camada 1. 


Modem DSL 


S 









Computador 


Digital Subscriber Line 
Access Multiplexer (DSLAM) 


Telefone 





Figura 5.51 
Telefone Rede de telefonia DSL. 


A tecnologia Digital Subscriber Line (DSL) foi desenvolvida para permitir o acesso às redes 
TCP/IP através da infraestrutura de telefonia com velocidades superiores às do acesso 
discado via modem, e do acesso digital via RDSI. Ela opera na camada física entre o equipa- 


mento do usuário e um concentrador de conexões DSL localizado no provedor de acesso. 


Intervalo de frequência de DSL 


DSL: 

a Usa intervalo de alta frequência a partir de 1 MHz. 
ADSL: 

ao Usao intervalo de frequência de 40 KHz até 1 MHz. 


a Não se sobrepõe ao intervalo de frequência de voz usado pelo sistema de telefonia 
(Plain Old Telephone Service - POTS), de 300 a 3.400 Hz. 


a Descongestiona as centrais telefônicas e as linhas de assinante. 


Figura 5.52 
Intervalo de 
frequéncia de DSL. 


SDSL 
POTS ADSL 


o 40 kHz 80 kHz 1 MHz 


DSL é uma familia de tecnologias de acesso que utilizam altas frequências (até 1 MHz) para 
entregar grande largura de banda sobre fios convencionais de cobre em distâncias limitadas. 


DSL (Digital Subscriber Line) é uma família de tecnologias desenvolvida para prover serviços 
de dados de alta velocidade utilizando pares de fios de cobre. Procura aproveitar a planta 
externa existente das companhias telefônicas para resolver o problema do acesso (última 


milha), possibilitando a prestação de serviços de dados com baixo custo de implantação. 


ADSL (Asymmetric DSL ou DSL assimétrico) é a forma mais conhecida, sendo utilizada 
predominantemente para acesso banda larga via internet. No ADSL, os dados são trans- 
mitidos de forma assimétrica. A taxa de transmissão na direção do assinante é maior 
(até 8 Mbps no ADSL normal e até 24 Mbps no ADSL2+) do que no sentido contrário (até 
1 Mbps no ADSL normal e no ADSL2+). Esta assimetria se deve ao fato de que o usuário 


faz muito mais downloads do que uploads. 


Com ADSL, o mesmo par de fios de cobre pode ser utilizado simultaneamente como linha 


telefônica e como acesso banda larga à internet, descongestionando as centrais telefônicas e 


a 


linha do assinante. A sigla POTS corresponde no Brasil à Rede Telefônica Pública Comutada 


(RTPC), rede de telefonia fixa. POTS e o serviço ADSL podem coexistir sobre o mesmo fio. 


Implementações de DSL 


Asymmetric: taxa de transmissão maior para downstream do que para upstream. 


Symmetric: mesma taxa de transmissão para downstream e upstream. 


ADSL. 

G.Lite ADSL. 
RADSL. 
VDSL. 


SDSL. 
G.SHDSL. 
HDSL/HDSL2. 





IDSL. 


ADSL é um tipo de DSL onde as larguras de banda upstream e downstream são diferentes. 
O ADSL é o mais comum dos xDSL. Configurações típicas atuais: 2 Mbps de downstream e 


128 Kbps de upstream. 


G.Lite ADSL (Splitterless DSL) é uma variante assimétrica do DSL, que não requer a adoção 
de um divisor de frequências (splitter) nas residências dos usuários para separar os canais 
do serviço de telefonia e do ADSL. G.Lite ADSL penaliza a taxa de transmissão em favor de 


operar sem divisor de frequências, reduzindo a complexidade e o custo de instalação. 
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ao RADSL (Rate Adaptive DSL) é uma variante assimétrica do DSL que pode ajustar a veloci- 
dade de upstream dependendo da distância e da qualidade da linha entre o assinante e 
a central (Central Office). Este ajuste é realizado na tentativa de manter uma boa veloci- 
dade de downstream. 


ao VDSL (Very-high-bit-rate DSL) é uma versão assimétrica do DSL que opera em velocidades 
muito elevadas. Opera em velocidades downstream e upstream de até 55 Mbps e 2.3 Mbps, 
respectivamente, mas somente a uma distância de até 300 m da central (Central Office). 


Pode chegar até 1.5 km em taxas mais baixas, em torno de 13 Mbps. 


ao SDSL (Symmetric DSL) é uma variante simétrica do DSL, onde upstream e downstream têm 
a mesma largura de banda. Opera tipicamente com taxa de 1,5 Mbps em ambas as dire- 


ções. Não opera simultaneamente com a conexão de voz no mesmo cabo telefônico. 


o G.SHDSL (Symmetric High-speed DSL) é uma variante de SDSL definida pelo padrão ITU 
G.991.2. Também não pode ser usado simultaneamente com a conexão de voz no mesmo 
cabo telefônico. Suporta velocidades simétricas de 192 a 2304 Kbps em um único par 
de fios, e 384 a 4608 Kbps em dois pares. Possui extensões que permitem o uso de até 
quatro pares de fios para incrementar as velocidades até 5696 Kbps. 


ao HDSL (High-bit-rate DSL) é uma variante simétrica pouco usada do DSL. Tipicamente 
opera a 2.048 Kbps, sendo equivalente a um tronco E1. HDSL requer dois pares de fios, 
enquanto HDSL2 suporta a mesma taxa de dados, mas usando um único par de fios. 


o IDSL (ISDN DSL) é um padrão que usa tecnologia baseada em ISDN para prover canais de 
comunicação em linhas telefônicas de até 144 Kbps. Está disponível onde outras opções 


do DSL, tais como o ADSL, não estão disponíveis. IDSL é lento e relativamente caro. 


io Descrição | Taxa | Modo | Distância À 


IDSL ISDN Digital 128 kbps Duplex 9.9 Km 
Subscriber Line 
HDSL High data rate 1.544 Mbps a Duplex 3.6 Km 
Digital Subscriber 42.048 Mbps 
Line 
SDSL Single Line Digital 1.544 Mbps a Duplex 3.6 Km 
Subscriber Line 2.048 Mbps 
ADSL Asymmetric Digital 1.5a 9 Mbps Down Up 5.5 Km 
Subscriber Line 16 a 640 kbps 
DSL Lite (G.Lite) ' Splitterless DSL 1.544 a 6 Mbps Down Up 6 Km 
16 a 640 kbps 
VDSL Very high data rate 13a 52 Mbps Down Up 1.3 Km 
Digital Subscriber 1.5 a 2.3 Mbps 
Lino Figura 5.53 
Implementações da 
ADSL tecnologia DSL. 


A tecnologia ADSL foi desenvolvida principalmente para usuários residenciais. Uma pessoa 
que se conecta à internet, em geral, recebe uma quantidade de dados muito maior do que 
envia, ou seja, utiliza muito mais downloads do que uploads. Com base nisso, foi desenvolvido 
um tipo de DSL assimétrico com taxas de transferência diferentes para download e upload, 
pois uma banda muito maior é utilizada para download. Assim, quando o usuário envia dados, 
ele não tem uma velocidade muito alta (apesar disso, ainda é maior do que a de uma conexão 


discada); mas quando recebe dados, a velocidade é aproximadamente 10 vezes maior. 


Figura 5.54 


Dados sobre ADSL. 


IP 182.183.1.3/24 
GW=182.183.1.1 








IP 182.183.1.4/24 
GW=182.183.1.1 


Ste Local Loop E4 = Cm Ste se 


CPE 
(Bridging) Router Router 


A principal vantagem das linhas ADSL é que o telefone pode ser utilizado simultanea- 
mente com a transferência de dados, pois a voz e os dados utilizam diferentes faixas 


de frequência. 


A modulação CAP, usada nas primeiras linhas ADSL, divide a banda da linha telefônica em três 
canais. O primeiro, que ocupa a faixa até 4 kHz, é exclusivo para voz. O segundo é exclusivo 
para envio de dados do usuário para o servidor (upload) e ocupa a faixa de 25 a 160 KHz. Já o 
terceiro canal, exclusivo para recepção de dados pelo usuário (download), ocupa a faixa que 
começa em 240 KHz e vai até, no máximo, 1,5 MHz. Como os três canais são bem definidos e 


espaçados entre si, reduz-se a probabilidade de interferência entre canais. 
ADSL2/2+ 


Em julho de 2002 foi criada a tecnologia ADSL2, logo aprovada pela ITU-T através dos padrões 
G.992.3 e G.992.4. Essa nova tecnologia de ADSL possui taxas de downstream de até 12 Mbps 
e upstream de 1 Mbps. Em 2005, foi concebido o ADSL2+ através do padrão G.992.5, definindo 


taxas de downstream de até 24 Mbps e mantendo a mesma taxa de 1 Mbps do ADSL2. 


O ADSL2 ainda possui a vantagem de economia de energia, pois o modem para esta tecno- 
logia foi projetado para funcionar somente quando o computador estiver em uso, ou seja, 
quando o computador entra em stand by, o modem também entra. Possui melhor modulação 
que o ADSL normal e um reordenador de tonalidades para dissipar os sinais de interferência 


causados pelas ondas de rádio AM, para ter um melhor ganho com a nova modulação. 


Dados sobre ADSL com bridging 


CJ 
o DSL é uma tecnologia de nível físico para transmissão sobre par trançado telefônico. 
a ATM éo protocolo que roda sobre o DSL. 


o DSLAM é o concentrador de conexões ADSL. 


A função do DSLAM é concentrar o tráfego de dados das várias linhas com modem DSL e 


conectá-lo com a rede de dados. 


A conexão através de circuitos ATM é a mais utilizada em redes ADSL. Existem equipamentos 
DSLAM que assumiram o papel de nó de acesso incorporando sistemas de comutação ATM. 
O CPE que fica no ambiente do usuário opera na modalidade de bridging, o que significa que 
funciona como um switch (comutador), executando funções de comutação da camada de 
enlace de dados, tipicamente operando como um switch Ethernet. 


DHCP Server 





Aggregation ISP/Corp 


ATM Dn 
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PPPoE 
PPPoE é uma solução de bridging semelhante as propostas apresentadas nos 
RFCs 1483 e 2684. 


O CPE faz bridging dos quadros Ethernet do computador do usuário ao roteador que 
agrega todas as conexões sobre ATM. Contudo, neste caso, o quadro Ethernet está carre- 


gando um quadro PPP encapsulado dentro dele. 


A sessão PPP é estabelecida entre o computador do usuário e o roteador agregador. 


Aggregation 
Router 


ocal Loo ~ E E oe 





ISP/Corp 
Router 


Figura 5.55 
Dados sobre 


g ADSL: PPPOE: 
O protocolo PPPoE (PPP over Ethernet) trabalha com a tecnologia Ethernet, que é usada para 


ligar a placa de rede ao modem, permitindo a autenticação para a conexão e a aquisição de um 
endereço IP para a máquina do usuário. É por isso que cada vez mais as empresas que oferecem 


ADSL usam programas ou o navegador de internet do usuário para que este se autentique. 


A Figura 5.56 ilustra as pilhas de protocolos envolvidas quando dados são enviados numa 
conexão ADSL utilizando PPPoE (PPP encapsulado em quadros Ethernet). 


Host PC Roteador de agregação 
IP IP 
PPP PPP 
PPPoE ADSL modem PPPoE 
Ethernet Ethernet 
Ethernet Ethernet ATM DSLAM ATM 
ADSL ADSL SDH ADSL 


IP 182.183.1.3/24 
GW=182.183.1.1 








IP 182.183.1.4/24 
GW=182.183.1.1 


Figura 5.56 

Pilhas de protocolos 
de dados sobre 
ADSL: PPPOE. 


CPE eM Roteador ISP/Corp 
(Bridging) de agregação Router 





Servidor DHCP 


oh Loop local E4 m~ Ste 


ATM tome DE 


Essa solução permite que a conexão PPP iniciada no roteador de agregação do provedor 
(Aggregation Router) seja terminada no Host PC do usuário. Isto é possível porque o Host PC 
tem placa de rede Ethernet. É por causa disso que o modem ADSL do provedor opera na 
modalidade de bridging, conectado à porta Ethernet do Host PC através de um cabo par 


trançado com conectores RJ-45, como se fosse um simples switch. 


Observe que, no lado do Host PC, o quadro PPP é encapsulado no quadro Ethernet (PPP 
over Ethernet - PPPoE) e é assim que ele chega no modem ADSL. No outro lado do modem 
ADSL, o protocolo de camada de enlace é ATM sobre ADSL na camada física. O DSLAM (DSL 
Access Multiplexor) multiplexa as conexões ATM em um enlace OC3 (155 Mbps) sobre SDH 
(Synchronous Digital Hierarchy) na camada física. Esse enlace OC3 termina no roteador de 
agregação do provedor onde toda a pilha de protocolos criada no Host PC é desencapsu- 
lada. O datagrama IP é então extraído do quadro PPP e roteado para a internet através da 


rede do provedor. 
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Figura 5.57 
Lista de 
equipamentos. 


Atividade 5.1- Configuração de VLANs 


Esta atividade esta dividida em quatro etapas: 


1. Descrição do caso; 


2. Projeto da rede; 


=F Roteiro de Atividades 5 


3. Configuração e verificação de VLANs em switches; 


4. Interconexão de VLANS via roteador. 


Descrição do caso 


Suponha que a você foi atribuída a tarefa de projetar e implementar a configuração dos 


equipamentos de uma rede corporativa, para interligar 50 dispositivos de rede (estações 


de trabalho, servidores e impressoras de rede). O prédio da empresa possui 3 andares e 


4 departamentos. A tabela seguinte lista a localização física, quantidade de cada tipo de 


dispositivo e departamento a que pertence cada um. 


Andar 
1º 
1º 
1º 
1º 
1º 


1º 


7 
x 
T 
z 
7 
F 


2° 


Equipamento 
: Computador 
Servidor 
Impressora 
Computador 
Servidor 


: Impressora 


Total 


: Computador 
Servidor 

Impressora 
Computador 
Impressora 
Computador 
Servidor 


: Impressora 


Total 


Qtde 


a 











17 


Departamento 


: Administrativo 
Administrativo 
Administrativo 
Tecnologia 
Tecnologia 


: Tecnologia 


: Administrativo 
Administrativo 
Administrativo 
Diretoria 
Diretoria 
Marketing 
Marketing 


; Marketing 
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Andar Equipamento Qtde Departamento 


Be : Computador : 1 : Administrativo 
3° : Computador 3) Diretoria 

Bo Servidor 2 Diretoria 

3° : Impressora 2 Diretoria 

Se Computador 5 Marketing 

3° Servidor 1 Marketing 

3° Impressora 1 Marketing 

3° : Computador : 2 : Tecnologia 

Se Impressora 1 Tecnologia 

i Total 18 


Na lista de compras da empresa estão homologados apenas switches de 24 portas Fast 
Ethernet e com duas portas GigabitEthernet de uplink (similar ao 2950 da Cisco) e um rote- 
ador com 3 interfaces seriais e 2 interfaces FastEthernet (similar ao 29xx da Cisco). 


Leve em consideração que a maior parte do tráfego é intradepartamental. Considere ainda que: 


VLANs devem ser utilizadas para separar os dominios de broadcast das redes departamentais. 
Deve ser criada uma VLAN apenas para gerência dos dispositivos de rede. 


Não é preciso se preocupar com a disposição dos equipamentos pelas portas de cada 
switch, pois haverá infraestrutura de cabeamento estruturado para dar total flexibilidade 
nesta tarefa. Ou seja, você pode arbitrar em que porta deseja colocar cada equipamento. 


Haverá uma sala de telecomunicações em cada andar, com bastidor para cada switch e 


servidores departamentais. 


Projeto da rede 


Uma das possíveis soluções de configuração é a seguinte: 
Um switch por andar, uma vez que em todos os andares existem menos de 24 equipamentos; 


Os switches devem estar interligados pelas portas de uplink Gigabit Ethernet que devem 
ser configuradas em modo “trunk link”; 


Um roteador com uma porta Ethernet; 


Cinco VLANs, uma para cada um dos 4 departamentos e uma para gerência. 


Figura 5.58 
Endereços dos 
gateways padrão 
das sub-redes. 


2. Uma possível solução de endereçamento IP é a seguinte: 





Rede Endereçamento IP Default Gateway VLAN ID 
Gerência 10.0.10.0/24 10.0.10.254/24 : 1 
Administração 10.0.20.0/24 10.0.20.254/24 2 
Diretoria 10.0.30.0/24 10.0.30.254/24 3 
Marketing 10.0.40.0/24 10.0.40.254/24 4 
Tecnologia 7 10.0.50.0/24 : 10.0.50.254/24 5 


Configuração e verificação de VLANs em switches 


1. Inicie o programa NetSimk. 
2. Clique em “File/Open”. 
3. Selecione o arquivo Rede_Atividade5_1.nsw. 


A topologia mostrada representa a solução descrita anteriormente. Os PCs já estão con- 
figurados com endereço IP, máscara de rede e gateway default. Vamos configurar os 3 
switches, de modo a colocar todos os computadores em suas respectivas VLANs. Para isso 
utilizaremos os PCs com cabos de console para configurar os switches, na porta serial COM 


indicada na ligação. 
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Figura 5.59 
Topologia da rede 
do laboratório. 


Para 


segu 


melhor visualizar a configuração dos switches, usaremos como referência a figura a 


ir, onde está esquematizada a configuração de cada switch. 


3º andar SW3 p VLAN2 - ADM (F0/1) 
Gm. vian3- DIR (F0/2-8) 

0/1 — > VLAN - MKT (F0/9-15) 

Ds eda VLANS - TEC (F0/16-18) 

ed | Lo VLANI - GER (F0/19-24) 


G0/1 
2° andar Trunk 802.1 Q 
SW2 
e. —— VLAN2 - ADM (F0/1-4) 


~ 1 VLAN3B - DIR (FO/5-7) 
Do viaN4-MKT(F0/817) 


SS viam - GER (F-18-24) 





G0/1 
1º andar Trunk 802.1 Q 
G0/1 
mae e ca A (F014 
Diagramade =. ~ DE “> TER) 


ligações da rede 


F0/23 | ` “Says VLANI - GER (F0/16-22,24) 


do laboratório. Roteador Sw1 


4. Configuração de VLANs no Sw: 


Sw 


Sw 


En 


Sw 


Sw 


>enable 
#conf t 
ter configuration commands, one per line. End with CNTL/Z. 


(config)#interface FastEthernet0/1 





(config-if)#switchport access vlan 2 


% Access VLAN does not exist. Creating vlan 2 


Sw 


Sw 


Sw 


(config-if)#switchport mode access 
(config-if)#interface FastEthernet0/5 


(config-if)#switchport access vlan 5 


% Access VLAN does not exist. Creating vlan 5 


Sw 


Sw 


Sw 


Sw 


Sw 


Sw 


(config-if)#switchport mode access 
(config-if)#interface FastEthernet0/24 
(config-if)#switchport access vlan 1 


(config-if)#switchport mode access 














(config-if)#Ctr1-Z 





fish vlan brief 
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VLAN Name Status Ports 

il default active Fa0/2, Fa0/3, Fa0/4, Fa0/6 
Fa0/7, Fa0/8, Fa0/9, Fa0/10 
Fa0/11, Fa0/12, Fa0/13, Fa0/14 
Fa0/15, Fa0/16, Fa0/17, Fa0/18 


FS, Fav/20,, Fa0/zi, Fa0/22 





Fa0/23, Fa0/24, Gi0/1, Gi0/2 


2 VLANOO02 active Fa0/1 
5 VLANOO05 active Fa0/5 
1002 fddi-default act/unsup 

1003 token-ring-default act/unsup 

1004 fddinet-default act/unsup 

1005 trnet-default act/unsup 

Swl# 


5. Configuração de VLANs no Sw2 
Sw2>en 


Sw2#conf t 

Enter configuration commands, one per line. End with CNTL/Z. 
Sw2(config)#interface FastEthernet0/1 
Sw2(config-if)#switchport access vlan 2 

% Access VLAN does not exist. Creating vlan 2 
Sw2(config-if)#switchport mode access 
Sw2(config-if)#interface FastEthernet0/5 
Sw2(config-if )#switchport access vlan 3 

% Access VLAN does not exist. Creating vlan 3 
Sw2(config-if )#switchport mode access 
Sw2(config-if)#interface FastEthernet0/8 
Sw2(config-if)#switchport access vlan 4 


% Access VLAN does not exist. Creating vlan 4 


Sw2(config-if)#switchport mode access 
Sw2(config)#interface FastEthernet0/24 
Sw2(config-if )#switchport access vlan 1 
Sw2(config-if)#switchport mode access 


Sw2#sh vlan brief 


VLAN Name Status Ports 

1 default active Fa0/2, Fa0/3, Fa0/4, Fa0/6 
Fa0/7, Fa0/9, Fa0/10, Fa0/11 
PaO, Faoi, Fa0/, Fatis 
Fa0/16, Fa0/17, Fa0/18, Fa0/19 


Fa0/20, Fa0/21, Fa0/22, Fa0/23 





Fa0/24, Gi0/1, 610/2 


2 VLANOO02 active Fa0/1 
3 VLANOO03 active Fa0/5 
4 VLANO004 active Fa0/8 
1002 fddi-default act/unsup 

1003 token-ring-default act/unsup 

1004 fddinet-default act/unsup 

1005 trnet-default act/unsup 

Sw2# 


6. Configuração de VLANs no Sw3 
Sw3>en 


Sw3#conf t 

Enter configuration commands, one per line. End with CNTL/Z. 
Sw3(config)#interface FastEthernet0/1 
Sw3(config-if)#switchport access vlan 2 

% Access VLAN does not exist. Creating vlan 2 
Sw3(config-if)#switchport mode access 


Sw3(config-if)#interface FastEthernet0/2 





Sw3(config-if)#switchport access vlan 3 
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% Access VLAN does not exist. Creating vlan 3 
Sw3(config-if)#switchport mode access 
Sw3(config-if)#interface FastEthernet0/9 
Sw3(config-if)#switchport access vlan 4 

% Access VLAN does not exist. Creating vlan 4 
Sw3(config-if)#switchport mode access 
Sw3(config-if)#interface FastEthernet0/16 
Sw3(config-if)#switchport access vlan 5 

% Access VLAN does not exist. Creating vlan 5 
Sw3(config-if)#switchport mode access 
Sw3(config-if)#interface FastEthernet0/24 
Sw3(config-if)#switchport access vlan 1 
Sw3(config-if)#switchport mode access 

Sw3#sh vlan brief 


VLAN Name Status Ports 


1 default active Fa0/3, Fa0/4, Fa0/5, Fa0/6 
Fa0/7, Fa0/8, Fa0/10, Fa0/11 
Fa0/12, Fa0/13, Fa0/14, Fa0/15 
Fa0/17, Fa0/18, Fa0/19, Fa0/20 
Fa0/21, Fa0/22, Fa0/23, Fa0/24 


Gi0/1, Gi0/2 





2 VLANO002 active Fa0/1 

3 VLANO003 active Fa0/2 

4 VLAN0004 active Fa0/9 

5 VLAN0005 active Fa0/16 
1002 fddi-default act/unsup 

1003 token-ring-default act/unsup 

1004 fddinet-default act/unsup 

1005 trnet-default act/unsup 

Sw3# 


7. Faremos agora a configuração IP para gerência dos switches: 
Swl#conf t 
Enter configuration commands, one per line. End with CNTL/Z. 
Swl(config)#interface vlan 1 
Swl(config-if)#ip address 10.0.10.1 255.255.255.0 


Swl(config-if)fno shutdown 








Swl(config-if)f 
HLDXX - Interface vlan 1, changed state to up 
Swi(config-if )#ex 


Swl(config)#ip default-gateway 10.0.10.254 


Sw2#conf t 

Enter configuration commands, one per line. End with CNTL/Z. 
Sw2(config)#interface vlan 1 

Sw2(config-if)#ip address 10.0.10.2 255.255.255.0 
Sw2(config-if)#no shutdown 

Sw2(config-if )# 

*LDXX - Interface vlan 1, changed state to up 
Sw2(config-if)#ex 


Sw2(config)#ip default-gateway 10.0.10.254 


Sw3#conf t 
Enter configuration commands, one per line. End with CNTL/Z. 


Sw3(config)#interface vlan 1 





Sw3(config-if)#ip address 10.0.10.3 255.255.255.0 
Sw3(config-if)#no shutdown 

Sw3(config-if )# 

*LDXX = terface vlan 1, changed state to up 


Sw3(config-if)#ex 








Sw3(config)#ip default-gateway 10.0.10.254 


Caso executasse um comando ping de qualquer computador para outro em uma mesma 
VLAN, você obteria sucesso? Para responder a essa pergunta, vamos fazer o seguinte teste: 


Execute o comando ping de Adm3 (IP: 10.0.20.9) para Adm2 (IP: 10.0.20.5), ambos da VLAN2. 
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O resultado deve ser parecido com o mostrado a seguir: 
Coping 10.0,.20.5 

Pinging 10.0.20.5 with 32 bytes of data: 
Ping request timed out. 

Ping request timed out. 


Ping request timed out. 














Ping request timed out. 


O ping não funcionou porque as portas Gigabit Ethernet dos switches Sw1, Sw2 e Sw3 não 
foram configuradas como “trunking link”. Portanto, os entroncamentos de VLAN não foram 
montados. Para montá-los, será necessário digitar os seguintes comandos nos 3 switches: 


Swl#conf t 

Enter configuration commands, one per line. End with CNTL/Z. 
Swl(config)#int gi0/1 

Swl(config-if)#switchport mode trunk 

Swl(config-if)#int gi0/2 


Swl(config-if)#switchport mode trunk 





Swl(config-if)# 


Após configurar todos os switches, para verificar se as portas Gigabit Ethernet estão “up”, 
digite o comando: 


Swl#sh int gi0/1 
GigabitEthernet0/1 is up, line protocol is up (connected) 


Hardware is Fast Ethernet, address is 932E.4600.101A (bia 
932E.4600.101A) 


TU 1500 bytes, BW O Kbit, DLY 2000 usec, rely 255/255, load 1/255 


Encapsulation ARPA, loopback not set, keepalive set (10 sec) 





Full-duplex, 1000Mb/s, media type is 1000BaseTX 
ARP type: ARPA, ARP timeout 00:05:00 


..blah blah blah - look at a real device... 





-- all sorts of stats such as packet rate, bad packets, 
broadcast packet count, late collision count, 
PUNCS Coke LOG smal- giants (Wke T00 Dic) CC 


Idem para a porta gi0/2, quando for usada. 


Figura 5.61 
subinterfaces do 
roteador. 


Agora o ping deve funcionar, conforme mostrado na listagem a seguir. 
C:>ping 10.0.20.5 

Pinging 10.0.20.5 with 32 bytes of data: 

Ping request timed out. 

Reply from 10.0.20.5 on Eth, tine Oms TTL=128 


Reply from 10.0.20.5 on Eth, time<lOms TTL=128 








Reply from 10.0.20.5 on Eth, time<lOms TTL=128 
Se não funcionar, corrija o erro. Se precisar, peça ajuda. 


Caso você executasse um comando ping de qualquer computador para outro em outra 


VLAN, você obteria sucesso? Para responder a essa pergunta, vamos fazer o seguinte teste: 
Execute o comando ping de Adm3 (IP: 10.0.20.9) da VLAN2 para Dir3 (IP: 10.0.30.4) da VLAN3. 
O resultado deve ser parecido com o mostrado a seguir. 

C:>ping 10.0.30.4 

Pinging 10.0.30.4 with 32 bytes of data: 

Ping request timed out. 

Ping request timed out. 


Ping request timed out. 














Ping request timed out. 

O ping não funcionou porque o roteamento entre VLANs não está configurado. 
Interconexão de VLANS via roteador 

Configuração de switches e roteador para roteamento entre VLANS. 


O roteador deve ficar no primeiro andar, ligado diretamente ao switch Sw1 em Fast Ethernet, 
já que não possui interface Gigabit Ethernet. Esta interface deve ter 5 subinterfaces para 
permitir o roteamento de tráfego entre as 5 VLANs. É preciso criar também um IP para cada 
subinterface do roteador em cada uma das 5 VLANs, com especificação do ID de VLAN, 


conforme a tabela abaixo. 


Subinterface Endereço IP VLAN ID 
FO/0.1 10.0.10.254/24 1 
FO/0.2 10.0.20.254/24 2 
FO/0.3 10.0.30.254/24 3 
F0/0.4 10.0.40.254/24 4 
F0/0.5 : 10.0.50.254/24 | 5 
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Configuração do roteador 
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ter>en 
ter#conf t 

ter con 

ter(co 
ter(config-subi 
ter(config-subi 
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ter(config-subi 
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figuration commands, one per line. End with CNTL/Z. 
fig)#interface FastEthernet0/0.1 

f)#description VLANI 

f)#encapsulation dotlq 1 

f)#ip address 10.0.10.254 255.255.255.0 

f)# 


*LDXX - Line protocol on Interface FastEthernet0/0, changed state 


*LDXX - Line protocol on Interface FastEthernet0/0.1, changed state 


f)#interface FastEthernet0/0.2 
f)#description VLAN2 
f)#encapsulation dotlq 2 


f)#ip address 10.0.20.254 255.255.255.0 





Di 


HLDXX - Line protocol on Interface FastEthernet0/0.2, changed state 


f)#interface FastEthernet0/0.3 
f)#description VLAN3 
f)#encapsulation dotlq 3 


f)#ip address 10.0.30.254 255.255.255.0 





Di 


*LDXX - Line protocol on Interface FastEthernet0/0.3, changed state 


f)#interface FastEthernet0/0.4 
f)#description VLAN4 
f)#encapsulation dotlq 4 


F)#ip address 10.0.40.254 255.255.255.0 





Di 


*LDXX - Line protocol on Interface FastEthernet0/0.4, changed state 


ter(config-subif )#interface FastEthernet0/0.5 


Figura 5.62 
Rede da 
Atividade 5.2. 


Router(config-subif)#description VLAN5 
Router(config-subif)#encapsulation dotlq 5 
Router(config-subif)#ip address 10.0.50.254 255.255.255.0 


Router(config-subif)# 





*LDXX - Line protocol on Interface FastEthernet0/0.5, changed state 
to up 





Configuração da porta do switch para o roteador 

Swl>enable 

Swl#conf t 

Enter configuration commands, one per line. End with CNTL/Z. 


Swl(config)#interface FastEthernet0/23 





Swl(config-if )#switchport mode trunk 

Vamos agora repetir o ultimo teste: 

Execute o comando ping de Adm3 (IP: 10.0.20.9) da VLAN2 para Dir3 (IP: 10.0.30.4) da VLAN3. 
C:>ping 10.0.30.4 

Pinging 10.0.30.4 with 32 bytes of data: 

Ping request timed out. 

Reply from 10.0.30.4 on Eth, time<l0ms TTL=127 


Reply from 10.0.30.4 on Eth, time<lOms TTL=127 











Reply from 10.0.30.4 on Eth, time<l0ms TTL=127 


Desta vez funcionou, porque o roteamento entre as VLANs está configurado corretamente. 


Atividade 5.2 - Configuração do protocolo PPP 


Configure dois roteadores 2501 de modo a estabelecer um enlace WAN ponto-a-ponto com 
o protocolo PPP, conforme a figura abaixo, utilizando o simulador NetSimk. Proceda con- 
forme o roteiro. Os roteadores estão conectados back to back usando cabo DTE de um lado e 
cabo DCE de outro. Nesse caso, o roteador DF será o DCE e o roteador RJ será o DTE. 








DF RJ 
t t ø 
----- 50 DCE SOB qu of 
+ + 
Roteador Roteador 


Os endereços IP das interfaces dos roteadores estão descritos na tabela a seguir. 


Nome do roteador Tipo de interface Endereço IP Máscara de rede 
DF : DCE É 20.0.01 : 255.0.0.0 
RJ : DTE : 20.0.0.2 : 255.0.0.0 
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1. Configure os nomes de cada roteador. 


Inicie o simulador Netsimk e carregue a rede Rede Atividade5 2.nsw, conforme a Figura 5.62. 
Para configurar o nome dos roteadores, faça o seguinte: 


Dê um duplo clique no PC de console do roteador DF. Em seguida, ative o HyperTerminal 


com um duplo clique. Na tela que surgir, digite os comandos: 

Router>en 

Router#conf t 

Enter configuration commands, one per line. End with CNTL/Z. 


Router(config)#hostname DF 





DF(config)# 


DF# 


o 


em para o roteador RJ, desta vez usando o outro PC de console: 

Router>en 

Router#conf t 

Enter configuration commands, one per line. End with CNTL/Z. 


Router(config)#hostname RJ 





RJ(config)# 





RJ# 


Neste ponto a sua figura deve ser idêntica à mostrada anteriormente. 


2. Sem alterar o modo de encapsulamento, configure e ative a interface do roteador RJ. 
Note que esta interface está operando como DTE. Usando o PC console do roteador RJ 


conforme mostrado acima, digite os comandos: 


RJ#conf t 
Enter configuration commands, one per line. End with CNTL/Z. 
RJ(config)#int ser0 


RJ(config-if)#ip address 20.0.0.2 255.0.0.0 











RJ(config-if)#no shut 
RJ(config-if)# 
RJ# 


3. Sem alterar o modo de encapsulamento, configure e ative a interface do roteador DF. 
Note que esta interface está operando como DCE e, portanto, precisa ter configurada a 


taxa de transmissão para fornecer o clock no enlace (clock rate). 


ee 


F#conf t 

Enter configuration commands, one per line. End with CNTL/Z. 
DF(config)#int ser0 

DF(config-if)#ip address 20.0.0.1 255.0.0.0 
DF(config-if)#clock rate 64000 


DF(config-if)#no shut 








DF(config-if)# 


LDX - Line protocol on Interface Serial 0, changed state to up 








Conforme a última mensagem, o enlace WAN está ativo (up). 
4. Para o roteador DF, verifique o estado da interface serial 0, digitando o comando: 
DF#sh int ser0 
Serial O is up, line protocol is up 
Hardware is HD64570 
Internet address is 20.0.0.1/8 


TU 1500 bytes, BW 10000 Kbit, DLY 2000 usec, rely 255/255, load 
1/255 


Encapsulation HDLC, loopback not set, keepalive set (10 sec) 


...blah blah blah - stats & settings - blah 





DF# 

Note que o encapsulamento é HDLC, por default. 

5. Para o roteador RJ, verifique o estado da interface serial O digitando o comando: 
RJ#sh int ser0 
Serial 0 is Up. Hne protocol 1s vo 
Hardware is HD64570 

Internet address is 20.0.0.2/8 


MTU 1500 bytes, BW 10000 Kbit, DLY 2000 usec, rely 255/255, load 
1/255 


Encapsulation HDLC, loopback not set, keepalive set (10 sec) 
...blah blah blah - stats & settings - blah 


RJ# 
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Note que o encapsulamento é HDLC, por default. 


6. Execute um comando ping de um roteador para outro. Funciona? Caso não funcione, 


verifique todas as configurações e corrija o erro. 


O resultado deve ser parecido ao mostrado a seguir: 
DF#ping 20.0.0.2 
Type escape sequence to abort. 


Sending 5, 100-byte ICMP Echoes to 20.0.0.2. 





Timeout is 2 seconds: 
Success rate is 100% (5/5), round trip min/avg/max = 8/9/10 ms 
DF# 


7. Altere o encapsulamento para PPP em ambos os roteadores. Para isso, digite os seguintes 


comandos nos respectivos consoles dos roteadores: 

DF#conf t 

Enter configuration commands, one per line. End with CNTL/Z. 
DF(config)#int ser0 

DF(config-if )#encap ppp 

DF(config-if)# 


*LDXX - Line protocol on Interface Serial O, changed state to down 





DF(config-if)# 





DF# 
Note que a interface está inativa (down). Por quê? 


Simplesmente porque a interface do roteador RJ na outra ponta do enlace está configurada 
com encapsulamento HDLC. A mesma coisa aconteceu com a interface do roteador RJ. 


RJ#conf t 
Enter configuration commands, one per line. End with CNTL/Z. 
RJ(config)#int ser0 

RJ(config-if )#encap ppp 

RJ(config-if)# 


*LDXX - Line protocol on Interface Serial 0, changed state to up 








RJ(config-if)# 








RJ 


Agora as duas interfaces estão ativas (up), uma vez que o encapsulamento está igual em ambas. 


8. Verificando o estado das interfaces dos dois roteadores: 
DF#sh int ser0 
Serial 0 Is up. lme protocol 1s wo 
Hardware is HD64570 
Internet address is 20.0.0.1/8 


MTU 1500 bytes, BW 10000 Kbit, DLY 2000 usec, rely 255/255, load 
1/255 


Encapsulation PPP, loopback not set, keepalive set (10 sec) 
LCP Open 

Open: IPCP, CDPCP 

soo Salm blan blan = Stats 4 serrcinas = oan sss 


DF# 


RJ#sh int ser0 

Serial 0 is up, line protocol is up 
Hardware is HD64570 

Internet address is 20.0.0.2/8 


TU 1500 bytes, BW 10000 Kbit, DLY 2000 usec, rely 255/255, load 
1/255 


Encapsulation PPP, loopback not set, keepalive set (10 sec) 





LCP Open 

Open: IPCP, CDPCP 

soo Salm blan blan = Stats 4 semcinos = ole se 
RJ# 


9. Execute um comando ping de um roteador para outro. Funciona? Caso não funcione, 


verifique todas as configurações e corrija o erro. 
O resultado deve ser parecido ao mostrado a seguir: 
RJ#ping 20.0.0.1 
Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echoes to 20.0.0.1. 
Timeout is 2 seconds: 
Success rate is 100% (5/5), round trip min/avg/max = 8/10/11 ms 


RJ# 
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10. Utilizando a autenticação CHAP, configure o nome e a senha do usuário no roteador DF. 
Siga o seguinte roteiro: 

DF#conf t 

Enter configuration commands, one per line. End with CNTL/Z. 
DF(config)#username RJ password esrrnp 

DF(config)#int ser0 


DF(config-if)#ppp authentication chap 





DF# 


11. Execute um comando ping de um roteador para outro. Funciona? Por quê? 


Não funciona porque apenas um dos roteadores foi configurado com autenticação. O resul- 


tado deve ser semelhante ao apresentado a seguir: 
DF#ping 20.0.0.2 
Type escape sequence to abort. 


Sending 5, 100-byte ICMP Echoes to 20.0.0.2. 





Timeout is 2 seconds: 

Success rate is 0% (0/5), round trip min/avg/max = 0/0/0 ms 
DF# 

12. Configure o nome e a senha do usuário no roteador RJ. 

Siga o seguinte roteiro: 

RJ#conf t 

Enter configuration commands, one per line. End with CNTL/Z. 
RJ(config)#username DF password esrrnp 

RJ(config)#int ser0 


RU(config-if)#ppp authentication chap 








RJ# 


13. Execute um comando ping de um roteador para outro. Funciona? Caso não funcione, 
verifique todas as configurações e corrija o erro. 


O resultado deve ser parecido ao mostrado a seguir: 
RJ#ping 20.0.0.1 
Type escape sequence to abort. 


sending 5- L100-byte ICNP Echoes to 20,00., 





Timeout is 2 seconds: 


Success rate is 100% (5/5), round trip min/avg/max = 8/10/10 ms 


RJ# 


Notas 


1. Ao final da atividade, os alunos devem salvar o arquivo corretamente configurado e 
funcionando com outro nome diferente de Rede_Atividade5_2.nsw (por exemplo: Rede_ 
Atividade5_2_OK.nsw). 


2. Embora a rede esteja funcionando corretamente, quando o arquivo corrigido é carregado 
novamente, o simulador acusa um erro de enable password. Além disso, os comandos ping 
entre os roteadores deixam de funcionar, ou seja, a conectividade entre eles é perdida. 


Essa mensagem de erro é informada quando clicamos no botão Check Configuration (botão 


verde no canto inferior direito). 


3. Para corrigir esse erro, é necessário digitar os seguintes comandos em ambos os roteadores: 


RJ#conf t 


Enter configuration commands, one per line. End with CNTL/Z. 
RJ(config)#enable password esrrnp 


RJ(config)# 





RJ# 
DF#conf t 

Enter configuration commands, one per line. End with CNTL/Z. 
DF(config)#enable password esrrnp 


DF(config)# 





DF# 


4. Agora os comandos ping devem funcionar. Quando for digitado o comando enable no início 
da operação de console dos roteadores, será solicitada uma senha. Basta digitar “esrrnp”. 
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Camada de rede 









Descrever as características do protocolo IPv4, os campos do cabeçalho e o 
processamento dos datagramas. Apresentar as principais mensagens de erro e 






objetivos 


controle do protocolo ICMP, ilustrando seu uso em aplicações de administração de redes. 








Funcionalidades e características da camada de rede: serviço de entrega de 





datagramas e roteamento. 


$O1199U09 







Este capítulo trata das funcionalidades e características da camada de rede: serviço de 


entrega de datagramas e roteamento. Descreve as características do protocolo IPv4, os 
campos do cabeçalho e o processamento dos datagramas. Também apresenta as principais 
mensagens de erro e controle do protocolo ICMP, ilustrando seu uso em algumas aplicações 


de administração de redes. 


Já vimos que a estrutura de interconexão de inter-redes TCP/IP é composta por um conjunto 
de redes físicas interconectadas por roteadores, que permitem que as várias estações se 
comuniquem entre si. Para que isso ocorra, as estações e roteadores devem suportar um 
serviço de entrega de pacotes que aceite datagramas IP e os encaminhe até o destino final, 


possivelmente por meio de diversas redes e roteadores intermediários. 


Funcionalidades da camada de rede 


O serviço de entrega aceita e encaminha os datagramas até o destino final, possivel- 
mente por meio de redes e roteadores intermediários. Já o roteamento determina o 
caminho ou rota que cada datagrama deve seguir para alcançar a rede de destino. 


Características da camada de rede: 

mn Serviço não confiável. 

a Não garante a entrega dos datagramas. 

a Pode perder, retardar e duplicar datagramas. 
a Não garante a integridade dos dados. 
Serviço sem conexão: 


a Datagramas são individuais e independentes. 





a Sequência dos datagramas não é assegurada. 
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E 
Paradigma de melhor esforço: 


a Descarta datagramas apenas em condições de falta de recursos ou erros de transmissão. | 


Na arquitetura TCP/IP, a camada de rede é responsável por prover e implementar o serviço 
de entrega de datagramas. Tecnicamente, esse serviço de entrega é definido como um 
serviço não confiável e sem conexão, que opera usando o paradigma de melhor esforço. 
Vamos entender melhor o que significa “não confiável”, “sem conexão” e “paradigma de 
melhor esforço”. 


O serviço de entrega de datagramas da arquitetura TCP/IP é considerado não confiável 
porque não garante que os datagramas sejam entregues com sucesso aos respectivos 
destinos finais. O serviço de entrega também não garante que o conteúdo dos datagramas 
entregues com sucesso esteja correto, pois nenhum mecanismo de detecção de erros é 
aplicado no campo de dados dos datagramas. O mecanismo de detecção de erros é aplicado 
somente sobre o cabeçalho do datagrama (Header checksum). A confiabilidade, se desejada, 


deve ser provida pelas camadas de transporte ou aplicação. 


O serviço é chamado sem conexão pelo fato de, antes do envio dos datagramas, não existir 
qualquer comunicação prévia entre as estações de origem e destino. Assim, a estação 
origem apenas monta o datagrama, acrescenta as informações de endereçamento que 
permitem o seu encaminhamento até o destino e o envia ao próximo roteador interme- 
diário ou, quando possível, diretamente à estação destino. Cada datagrama é tratado de 
forma individual e completamente independente dos demais. Logo, nenhuma informação é 
mantida sobre a sequência dos datagramas enviados e assim não é possível descobrir se um 
pacote foi recebido duplicado, fora de ordem ou perdido. Uma analogia pode ser feita com o 


serviço de carta simples do correio postal. 


O paradigma de melhor esforço (best effort) recebe essa designação porque tenta realizar a 
entrega dos pacotes com o melhor aproveitamento possível. Ou seja, pacotes somente são 
descartados em condições de escassez de recursos ou erros de transmissão que impeçam a 
entrega. Por exemplo, quando um roteador não dispõe de buffer de recepção, pacotes são 


simplesmente descartados. 


Roteamento de redes 


Modelo passo-a-passo: 
a Estações de uma mesma rede podem enviar datagramas diretamente entre si. 


a Estações de redes distintas devem enviar datagramas ao próximo roteador do 


caminho (next-hop). 
Tabela de roteamento: 
a Mantém rotas para as diversas redes ou estações. 
a Rotas indicam apenas o próximo roteador do caminho. 


Para realizar a entrega de datagramas, a camada de rede deve executar a função de rotea- 
mento, determinando o caminho ou rota que cada datagrama deve seguir para alcançar a 


estação de destino. Na arquitetura TCP/IP, a camada de rede adota o modelo de roteamento 


hop-by-hop (passo-a-passo). Nesse modelo, se as estações origem e destino estão conectadas 
à mesma rede física, a estação origem pode enviar o datagrama diretamente à estação destino. 
No entanto, se as estações origem e destino estão conectadas a redes físicas distintas, a 
estação origem envia o datagrama ao próximo roteador do caminho (next-hop), que agora 


assume a responsabilidade de continuar encaminhando o datagrama ao destino. 





Buffer 


Espaço de memória 
reservado para arma- 
zenar pacotes recebidos 
(buffer de recepção) 

ou a serem enviados 
(buffer de transmissão). 


Roteamento 
hop-by-hop 

Técnica de roteamento 
em que a estação 
origem e cada rote- 
ador intermediário 
entregam o datagrama 
ao próximo roteador do 
caminho, até que algum 
deles possa entregar o 
datagrama diretamente 
a estação destino. 


Saiba mais 


Para mais detalhes, 
sugerimos aos interes- 
sados uma consulta 
ao livro: FALL, Kevin R.; 
STEVENS, W. Richard. 
TCP/IP Illustrated 


Volume 1: The Protocols. 


Addison Wesley, 2011. 





Cada roteador intermediário entrega o datagrama ao próximo roteador, até que algum deles 
possa entregar o datagrama diretamente à estação destino. Como pode ser observado, a 


função de roteamento explora os mecanismos de entrega direta e indireta. 
Tabela de roteamento 


A tabela de roteamento é a estrutura de dados mantida por todas as estações e roteadores 
de uma inter-rede. Ela contém informações sobre as rotas para alcançar as possíveis redes 


ou estações de uma inter- rede. 


A implementação da camada de rede mantém em memória informações de roteamento, 
armazenadas em uma tabela de roteamento. Essa tabela é consultada para descobrir a 

rota a ser adotada para encaminhar cada datagrama. Na tabela de roteamento, as entradas 
representam as rotas para cada destino possível da inter-rede. Cada rota sinaliza como 
alcançar uma determinada rede ou uma estação específica. Vale ressaltar que, na prática, 
as rotas geralmente apontam para redes, reduzindo o tamanho da tabela e tornando o rote- 
amento mais eficiente. Além de algumas informações auxiliares, cada rota possui apenas o 
endereço IP do próximo roteador que deve ser usado para alcançar a rede ou estação indi- 
cada na rota. Geralmente, esse próximo roteador reside em uma rede diretamente conec- 


tada, permitindo que o datagrama lhe seja entregue. 


Observe que as rotas não indicam o caminho completo até o destino, mas apenas o ende- 
reço IP do próximo roteador. Assim, no modelo de roteamento da arquitetura TCP/IP, esta- 


ções origem e roteadores intermediários não conhecem a rota completa até o destino. 


Protocolos da camada de rede 


o IP - provê o serviço de entrega de datagramas e transporta informações dos 
protocolos ICMP, IGMP, TCP e UDP. 


o ICMP - permite a troca de mensagens de erro e controle entre entidades da camada 


de rede. 


o IGMP - provê o serviço de entrega multicast. 


Para prover o serviço de entrega de datagramas e a função de roteamento, a camada de 
rede da arquitetura TCP/IP define três protocolos complementares: 


a IP -o Internet Protocol provê um serviço de entrega de datagrama não confiável. É um dos 
mais importantes protocolos da família TCP/IP, pois todos os demais protocolos das camadas 
de rede e transporte dependem dele para entregar partes de suas informações. Em outras 
palavras, ICMP, IGMP, UDP e TCP são diretamente encapsulados em datagramas IP. 


a ICMP -o Internet Control Message Protocol auxilia o protocolo IP, sendo usado para 
trocar mensagens de erro e de controle, sinalizar situações anormais de operação e per- 


mitir a identificação de informações operacionais da rede. 


o IGMP -o Internet Group Management Protocol é responsável pela entrega de datagramas 
a múltiplos destinos, suportando assim o mecanismo de entrega multicast da arquitetura 
TCP/IP. O estudo detalhado do protocolo IGMP está fora do escopo deste curso. 


Protocolo IP 


Ea 
O protocolo IP define a unidade básica de transferência de dados, denominada “data- 
grama IP”, especificando o formato e a função dos campos. Ele executa a função de 


roteamento e escolhe as rotas por onde os datagramas IP são enviados da origem para o 
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a Como datagramas são processados. 

a Comoe quando erros são informados. 

a Quando datagramas são descartados. 

O protocolo IP define três importantes conceitos: 

ao Especifica, de forma precisa, o formato da unidade básica de transferência de dados 
usada em redes TCP/IP, denominada datagrama IP. 


a Executa a função de roteamento, escolhendo os caminhos pelos quais os datagramas são 


enviados da estação origem para a estação destino. 


ao Define um conjunto de regras para o serviço de entrega de datagramas, que caracterizam 
a forma como estações e roteadores devem processar datagramas, como e quando 
mensagens de erro devem ser geradas e as condições sob as quais datagramas podem 
ser descartados. 


Neste capítulo, vamos identificar o formato e os campos dos datagramas IP, evidenciando 
como são utilizados para compor o serviço de entrega de datagramas. Vamos discutir, 


também, as regras para o processamento de datagramas. 


Por enquanto, é suficiente saber que a função de roteamento seleciona os melhores cami- 
nhos através dos quais datagramas são enviados. 


Campos do datagrama 


a Source IP address 
m Endereço IP da estação origem. 
a Destination IP address 
m Endereço IP da estação destino. 
a Usado no roteamento do datagrama. 
a Version 
m Versão do protocolo (IPv4). 
o Hlen 
m Tamanho do cabeçalho em unidades de 4 bytes. 
o Total length 
m Tamanho total do datagrama em bytes. 
m Cabeçalho e dados incluídos. 
o Timeto Live (TTL) 
m Número máximo de roteadores que podem processar o datagrama. 
a TTL é decrementado a cada roteador, antes de processar o datagrama. 


a Roteador descarta o datagrama e gera mensagem de erro ICMP quando TTL 
atinge 0. 


a Protocol 
m Protocolo encapsulado no campo de dados. 
a Header checksum 


m Assegura a integridade do cabeçalho. 


o Options 
a Oferece informações para teste e depuração. 
m Torna o tamanho do cabeçalho variável. 
ao Padding 
a Bits O que tornam o cabeçalho múltiplo de 32 bits. 
o Data 
m Dados do datagrama. 
o Type of Service (TOS) - RFC 791 (original) 
a Indica a qualidade de serviço desejada 
a Precedence: prioridade 
a D:menor retardo 
a T; maior vazão 


a R: maior confiabilidade 





o Differentiated Services Codepoint (DSCP) - RFC 2474 


Cada datagrama IP é dividido em duas partes: cabeçalho e dados. O cabeçalho contém infor- 
mações de controle específicas do protocolo IP, como os endereços IP de origem e destino. 
A porção dos dados encapsula informações de outros protocolos da própria camada de rede 
(ICMP e IGMP) ou da camada de transporte (TCP e UDP). 


A Figura 6.1 ilustra o formato de datagramas IP, detalhando o formato dos campos que 


compõem o cabeçalho. 


Figura 6.1 
Layout do 
datagrama IP. 





O formato do campo de dados não é explicitamente definido, para permitir o encapsula- 


mento de diferentes protocolos. 


o Source IP address e Destination IP address - campos usados com o propósito de 
transportar os endereços IP das estações origem e destino. Cada um desses campos 
possui exatamente 32 bits. Na estação origem e em cada roteador intermediário, 
somente o campo Destination IP address é usado para descobrir uma rota na tabela 
de roteamento, identificando o próximo roteador do caminho até a rede da estação 
destino. Por outro lado, na estação destino, o campo Destination IP address revela que o 


datagrama alcançou o destino final. 
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Version - campo que identifica a versão do protocolo IP usada para compor o datagrama. 
Todas as implementações do protocolo IP devem verificar este campo, assegurando que 
a versão indicada pode ser processada corretamente. Caso contrário, o datagrama é sim- 
plesmente descartado. A versão mais utilizada do protocolo IP é a 4, denominada IPv4; no 
entanto, a nova versão 6 (IPv6) deverá substituí-la em breve. 


Hlen - Header length é o campo que identifica o tamanho do cabeçalho em múltiplos 

de 32 bits. O tamanho do cabeçalho é variável, mas sempre múltiplo de 32 bits. Por 
exemplo, hlen igual a 5 representa um cabeçalho de 20 bytes. Geralmente, o cabeçalho 
possui 20 bytes, exceto quando opções estão presentes (options). O cabeçalho é limitado 
a 60 bytes, pois h/en possui apenas 4 bits. 


Total length - campo que informa o tamanho total (cabeçalho + dados) do data- 
grama, em bytes. Se esse campo é de 16 bits, então o maior datagrama possível tem 
65.535 (21º) bytes. Portanto, o tamanho do campo de dados pode ser calculado por: 
Total length - 4 * Hlen. 


Time to Live - TTL é o campo que informa o número máximo de roteadores por meio 
dos quais o datagrama pode ser encaminhado para alcançar o destino. Isso serve para 
evitar que datagramas circulem indefinidamente por causa de problemas de loops de 
roteamento. O valor inicial é definido pela estação origem, que geralmente atribui o 
valor 32 ou 64. A partir de então, cada roteador intermediário que processa o datagrama 
deve decrementar de um o valor do TTL, antes de processar o datagrama. Quando o TTL 
assume o valor 0, o datagrama é descartado e o roteador intermediário envia uma men- 
sagem de erro ICMP para a estação origem. 


Protocol - campo responsável por identificar o protocolo encapsulado no campo de 
dados. Os valores 1, 2, 6 e 17 são padronizados para sinalizar o encapsulamento dos 
protocolos ICMP, IGMP, TCP e UDP, respectivamente. Esse campo é usado na estação 
destino para realizar o desencapsulamento, entregando a unidade de dados encapsulada 


no datagrama IP ao protocolo indicado. 


Header checksum - campo utilizado para realizar a detecção de erros de transmissão no 
cabeçalho dos datagramas IP, de modo a assegurar sua integridade. Assim, o protocolo IP 
não assegura a integridade do campo de dados, mas apenas do cabeçalho. Essa abor- 
dagem reduz o tempo de processamento dos datagramas, mas impõe que os protocolos 
encapsulados realizem a detecção e possível correção de erros. Quando a implemen- 
tação do protocolo IP detecta um erro no cabeçalho, o datagrama é simplesmente des- 


cartado, e nenhuma mensagem de erro é enviada à estação origem. 


Options - apresenta lista de informações opcionais, usadas principalmente para teste 
e depuração. Por exemplo, é possível indicar ou registrar a rota usada pelo datagrama, 
bem como sinalizar algumas restrições de segurança. Essa lista possui um tamanho 
variável, podendo aparecer várias opções em um mesmo datagrama, embora, na 
prática, raramente essas opções sejam usadas. Assim, as diversas opções existentes 
não serão avaliadas. 


Padding - campo que contém bits O que estendem o cabeçalho para torná-lo múltiplo 
de 32 bits. Assim, o campo Padding somente é usado quando o campo Options, que é 


variável, não é múltiplo de 32 bits. 


Identification, Flags e Fragment offset - campos usados no processo de fragmentação 
e remontagem de datagramas. Em função de sua importância, esse processo será estu- 


dado separadamente no próximo item. 


Figura 6.2 
Campo TOS 
segundo o RFC 791. 


Figura 6.3 
Campo ToS segundo 
o RFC 2474. 


Taxa de transmissdo de 
dados obtida em um 
determinado enlace de 
rede ou conjunto de 
enlaces que compõem 
a rota entre duas esta- 
ções. Em geral, a vazão 


é medida em bits por : a Cada tecnologia de rede física limita o tamanho máximo do quadro. 


segundo. 


Confiabilidade 


Grau de imunidade a 
erros de transmissão de 
um determinado enlace 

ou conjunto de enlaces 
que compõem a rota 
entre duas estações. 

Uma baixa confiabili- 

dade representa que o 
canal de transmissão 
é propenso a erros de 
transmissão. Já uma 
alta confiabilidade 
representa que o canal 
de transmissão é 
imune a erros. 


; oa Tamanho máximo do datagrama depende da tecnologia de rede física utilizada. 


im Tamanho máximo do campo de dados de uma rede física é denominado MTU. 


o Type of Service (TOS) - campo usado para indicar a qualidade de serviço desejada. Esse 
campo possui 8 bits. Na especificação do RFC 791 do IP, esse campo era dividido em 
5 subcampos, conforme ilustra a Figura 6.2. Por não ser suportado por todas as imple- 
mentações do protocolo IP, a qualidade de serviço requisitada não é garantida no proces- 


samento e roteamento do datagrama. 


0 1 2 3 4 5 6 7 
C PECE) 


Essa definição foi alterada posteriormente pelos RFCs 1349 e 2474. O campo Type of Service é 
também utilizado para prover qualidade de serviço em serviços diferenciados (Differentiated 
services), conforme mostra a Figura 6.3, na qual a denominação atual é DSCP (Differentiated 


Services CodePoint) - U: unused. 


0 1 2 3 4 5 6 7 


o Precedence - subcampo que possui 3 bits que sinalizam a prioridade de processamento 
do datagrama. Assim, 7 níveis de prioridade são definidos, com variação de normal (000) 


até controle de rede (111). 


a Subcampos D, T eR - sinalizam o tipo de transporte requerido, auxiliando a função 
de roteamento na seleção da rota mais adequada. Cada um desses subcampos possui 
apenas um único bit. Os subcampos D, T e R requisitam rotas de menor retardo (delay), 
maior vazão (throughput) e maior confiabilidade (reliability), respectivamente. Apenas 


um desses bits pode ser habilitado (1) em um datagrama. Se todos estiverem desabili- 


tados (0), a função de roteamento normal é realizada. 


Fragmentação e remontagem 


Maximum Transmission Unit (MTU): 


a MTU define o tamanho máximo do datagrama IP suportado na rede física. 
Fragmentação: 

a Processo de divisão de datagramas em pequenas partes, denominadas fragmentos. 
oa Fragmentos e datagramas possuem formatos idênticos. 

ao Datagrama original e seus respectivos fragmentos possuem cabeçalhos similares. 

o Fragmentos podem ser refragmentados. 

Remontagem: 

a Processo de recuperação do datagrama original a partir dos seus fragmentos. 

a É realizada apenas no destino final dos fragmentos. 


a O datagrama original não pode ser remontado quando algum fragmento atrasa 


ou é perdido. 
m Destino final ativa um temporizador após a chegada de um fragmento. 


m Fragmentos recebidos após expirar o temporizador são descartados. 
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Cada tecnologia de rede física impõe um limite no tamanho máximo do quadro. Logo, 

o tamanho máximo do datagrama IP que pode ser encapsulado no campo de dados do 
quadro é dependente da tecnologia da rede física utilizada. A Maximum Transmission Unit 
(MTU) ou unidade de transmissão máxima é a forma de denominar esse limite. Ela define o 


tamanho máximo do datagrama IP que pode ser encapsulado no quadro daquela rede. 


Geralmente, a estação de origem seleciona o tamanho máximo de um datagrama IP com 

base na MTU da rede física diretamente conectada que será usada para transmiti-lo. Como 

um datagrama pode ser encaminhado por redes físicas distintas, com MTUs diferentes, o 

tamanho inicial do datagrama pode não ser adequado nas demais redes intermediárias. Isso 

requer algum mecanismo para dividir o datagrama em pequenas partes. Cada uma destas 

partes é denominada fragmento, enquanto o processo de divisão dos datagramas é deno- 

minado fragmentação. Cada fragmento possui o mesmo formato de um datagrama IP, com Fragmentação 


um cabeçalho semelhante ao cabeçalho do seu respectivo datagrama original. A Figura 6.4 Processo de divisão de 
um dado datagrama 
em outros datagramas 
menores, denominados 


mostra um cenário em que o processo de fragmentação pode ocorrer. 


Sempre que a estação E1 enviar para a estação E2 datagramas maiores que 420 bytes, o 


fragmentos. 
roteador R1 deve fragmentar esses datagramas para enviá-los através da rede N2, gerando 
fragmentos menores ou iguais a 420 bytes. A fragmentação também deve ocorrer quando a 
estação E2 enviar para a estação E1 datagramas maiores que 420 bytes. Porém, neste caso, 
o roteador R2 é o responsável pelo processo de fragmentação. 
É possível um fragmento ser diversas vezes fragmentado em outros roteadores ao longo do Figura 6.4 
Exemplo de 


caminho até o destino. As informações mantidas nos cabeçalhos dos fragmentos permitem a 
fragmentação do 


reconstrução do datagrama original, independente do número de fragmentações ocorridas. datagrama IP 





MTU = 1500 MTU = 420 MTU = 1500 


Antes de serem processados no destino final, fragmentos devem ser agrupados para 
produzir uma cópia do datagrama original. O processo de recuperação do datagrama 


original a partir dos seus fragmentos é denominado remontagem. Para evitar diversas Remontagem 


fragmentações e remontagens, que consomem tempo de processamento dos roteadores e Processo de 
recuperação do 
datagrama original a 
partir dos diversos 
dente até o destino, onde, então, o datagrama original é remontado a partir dos seus fragmentos gerados 


retardam a entrega dos datagramas, o processo de remontagem é realizado apenas no 


destino final. Dessa forma, cada fragmento é encaminhado como um datagrama indepen- 


respectivos fragmentos. pela fragmentação. 


Como o protocolo IP adota um serviço de entrega não confiável, os fragmentos podem ser 
perdidos e, em consequência, o datagrama original não pode ser remontado. Para tratar 
esse caso, um temporizador de remontagem é iniciado quando um fragmento de um novo 
datagrama chega à estação destino. Se esse tempo expira antes da chegada de todos 

os fragmentos, a estação simplesmente descarta os fragmentos recebidos e, assim, não 
remonta o datagrama original. 


Controle de fragmentação 


cada fragmento. J 


o Identification - número inteiro que identifica o datagrama original, copiado para 


Fragment Offset - deslocamento dos dados do fragmento em relação ao 


datagrama original; indicado em unidades de 8 bytes. 


Flags - conjunto de três bits que auxiliam o processo de fragmentação; apenas dois 


bits são usados. 
Do not fragment - desabilita a fragmentação. 


More fragments - indica se o fragmento transporta dados do fim do datagrama original. 


Para controlar os processos de fragmentação e remontagem, o protocolo IP usa os campos 


Identification, Fragment offset e Flags: 


Identification - campo que contém um número inteiro que identifica o datagrama 
original. Quando ocorre a fragmentação, o campo Identification do datagrama é sim- 
plesmente copiado para cada fragmento. Baseada nos campos Identification e Source 
IP address, a estação destino pode identificar todos os fragmentos de um determinado 


datagrama. 


Fragment offset - campo que identifica o deslocamento dos dados transportados, em 
cada fragmento, em relação ao datagrama original. Esse deslocamento é medido em 
unidades de 8 bytes. Dessa forma, a quantidade de dados transportada nos fragmentos 
deve ser múltipla de 8. O primeiro fragmento de um datagrama possui o valor O no 
campo Fragment offset. Para remontar o datagrama original, a estação destino posiciona 
cada fragmento de acordo com o respectivo campo Fragment offset. 


Flags - campo de três bits, dos quais dois (Do not fragment e More fragments) são usados 
no controle de fragmentação, e um é reservado para uso futuro. Como o próprio nome 
indica, o bit Do not fragment sinaliza se o datagrama pode (0) ou não (1) ser fragmentado. 
Esse bit pode ser usado para descobrir o tamanho de datagrama que deve ser usado 
para evitar a fragmentação entre duas estações. Por outro lado, o bit more fragments 
sinaliza se o fragmento contém dados do início/meio (1) ou do final (0) do datagrama 
original. A estação destino usa o bit More fragments para detectar o último fragmento de 


um datagrama. 


Para um melhor entendimento desses processos, vamos realizar a fragmentação e remon- 


tagem de um datagrama de 1000 bytes enviado pela estação E1 à estação E2 da Figura 6.5. 


Nesse caso, 0 datagrama possui um cabeçalho de 20 bytes e transporta 980 bytes de dados. 


Para simplificar, vamos citar apenas os campos do cabeçalho que estão relacionados à frag- 


mentação e à remontagem. 
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MTU = 1500 MTU = 420 MTU = 1500 
More Fragment Total 
Identification fragments offset length Data 
5000 Le 100 200 180 Fragmento f3 
a Inicialmente, a estação E1 gera o datagrama d, ilustrado na Figura 6.5. No roteador R1, Figura 6.5 
em função da MTU da rede N2, o datagrama é fragmentado, gerando os fragmentos f1, Exemplo de 


fragmentação do 


f2 e f3, de tamanho menor ou igual a 420 bytes, conforme ilustra a figura, onde podemos datagrama IP. 


observar que: 


O campo Identification é copiado do datagrama original para cada fragmento. 


Apenas o bit More fragments do último fragmento (f3) é igual a 0, indicando que este frag- 
mento transporta o final do datagrama original. Nesses fragmentos, estamos assumindo 


que o tamanho dos cabeçalhos é igual a 20 bytes. 


O campo Fragment offset de cada fragmento sinaliza a posição dos dados no datagrama 
original. Como o Fragment offset é representado em unidades de 8 bytes, os fragmentos 
f1, f2 e f3 iniciam nas posições 0, 400 e 800 do datagrama original d. 


O campo Total length não é copiado do datagrama original, mas modificado para indicar o 


tamanho do próprio fragmento. 


Processo de remontagem 


CJ 
Os campos Identification e Source IP address identificam os fragmentos de um datagrama. 


Primeiro fragmento identificado pelo Fragment offset 0. 


Fragmentos intermediários são posicionados de acordo com o seu Fragment offset. 


Último fragmento é detectado por More fragments. 


Na remontagem, a estação E2 percebe que f1 é o primeiro fragmento do datagrama original, 


pois o seu Fragment offset é 0. 


Por outro lado, E2 detecta que f3 é o último fragmento, pois o seu bit More fragments é O. Por 
fim, considerando a quantidade de dados do fragmento f1 (Total length - 4 * Hlen) e o desloca- 


mento do fragmento f3 (Fragment offset), E2 detecta que f2 é o único fragmento intermediário. 
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Processamento de datagramas 
Ea 

Conjunto de regras que caracterizam o serviço de entrega de datagramas. Estações e 

roteadores podem: 

a Enviar datagramas, atuando como origem. 

o Receber datagramas, atuando como destino. 


a Roteadores intermediários podem rotear datagramas, encaminhado-os de uma rede 





física para outra. 


Em redes TCP/IP, estações e roteadores podem enviar e receber datagramas, atuando como 
origem e destino desses datagramas, respectivamente. Além disso, roteadores podem 


rotear datagramas, encaminhando-os de uma rede física para outra. 


Para tratar adequadamente cada um destes casos, o protocolo IP define um conjunto de 
regras para o processamento de datagramas que caracterizam o serviço de entrega provido 
pela camada de rede. Essas regras indicam, inclusive, como e quando datagramas podem 
ser descartados e mensagens de erro que devem ser geradas. O processamento de data- 


gramas é realizado da seguinte forma: 


1. Na origem, a estação (ou roteador) monta o datagrama, preenchendo os diversos campos 
do cabeçalho. Em seguida, a estação consulta a tabela de roteamento para descobrir 
uma rota para alcançar a estação destino, podendo enviá-lo direta ou indiretamente ao 
destino: envia diretamente se as estações origem e destino estão conectadas na mesma 
rede física; ou indiretamente, via um roteador intermediário, se as estações de origem e 


destino estão conectadas em redes físicas diferentes. 


2. No destino, caso disponha de espaço no buffer de recepção, a estação (ou roteador) 
recebe e armazena uma cópia do datagrama. Caso contrário, o datagrama é simples- 


mente descartado e uma mensagem de erro ICMP é enviada para a estação origem. 


3. Após armazenar uma cópia do datagrama, a integridade do cabeçalho é verificada com 
base no campo Header checksum. Se um erro é detectado, o datagrama é imediatamente 
descartado. Senão, a implementação do protocolo IP verifica se o datagrama é realmente 
endereçado àquela estação, avaliando se o endereço IP de destino é igual a algum dos 
endereços IP daquela estação. Vale lembrar que uma estação multihomed (ou roteador) 
possui diversos endereços IP e que o conceito de IP Aliasing permite a atribuição de múlti- 


plos endereços IP a uma única interface de rede. 


4. Se a estação não é o destino, o datagrama é descartado, mas não nos roteadores inter- 
mediários, como será explicado adiante. Se a estação (ou roteador) é o destino, a imple- 
mentação do protocolo IP verifica se o datagrama recebido é um datagrama completo ou 


apenas um fragmento. 


5. No caso de um datagrama completo, a unidade de dados encapsulada é entregue ao pro- 
tocolo de transporte indicado no campo Protocol. No caso de um fragmento, um tempori- 


zador é inicializado para aguardar a chegada dos outros fragmentos. 


6. Se nem todos chegam antes do estouro do temporizador, então os fragmentos recebidos 
são descartados e uma mensagem de erro ICMP é enviada para a estação de origem. 
Caso contrário, se todos chegam antes do estouro do temporizador, o datagrama original 
é remontado e a unidade de dados encapsulada é repassada à camada de transporte. 
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7. 


Em um roteador intermediário, se existe espaço no buffer de recepção, o datagrama é 


recebido e armazenado. Caso contrário, o datagrama é descartado. 


Em seguida, a integridade do cabeçalho é verificada. Em caso de erro, o datagrama 
também é descartado. Caso contrário, percebendo que o endereço IP de destino não é 
igual a nenhum dos endereços IP daquele roteador, a implementação do protocolo IP 
decide rotear o datagrama para o destino. 


Q) Em um roteador intermediário, o datagrama recebido nunca é endereçado para ele. 


10. 


11. 


Nesse ponto, o TTL do datagrama é decrementado de um. Se o valor do TTL atinge o valor 
0, o datagrama é descartado e uma mensagem de erro ICMP é enviada à estação origem. 
Senão, o roteador consulta a tabela de roteamento para descobrir uma rota para alcançar 


o destino, podendo enviá-lo diretamente ou indiretamente via outro roteador. 


Antes de enviar o datagrama, a implementação do protocolo IP avalia a necessidade de 
fragmentação, considerando a MTU da rede física e o tamanho do datagrama. Caso seja 


necessário, o datagrama original (ou fragmento) é dividido em fragmentos. 


Cada fragmento ou o próprio datagrama original é enviado pela rota selecionada. Se a 
fragmentação deve ser realizada, mas o campo Do not fragment a desabilita, então o data- 
grama é descartado e uma mensagem de erro ICMP é enviada à estação de origem. Essa 
é a forma, já mencionada, de utilizar o campo Do not fragment para descobrir o tamanho 


de datagrama que deve ser utilizado para evitar a fragmentação entre duas estações. 


Processamento na origem 


Encaminha para 
próximo roteador 


Monta o datagrama 

m Preenche os campos do cabeçalho. 

Descobre rota para o destino. 

Envia o datagrama 

a Entrega direta ao destino, se origem e destino estão na mesma rede física. 


a Entrega indireta a um roteador intermediário, se origem e destino estão em redes 
físicas distintas. 


Montagem 
do datagrama 







Entrega 
direta? 


a Encaminha para 
a estação destino 





Figura 6.6 
Processamento na 
estação origem. 


Processamento no destino 


a Recebe e armazena datagrama 
m Descarta datagrama e gera mensagem de erro quando não possui buffer. 
ao Verifica integridade do cabeçalho 
a Descarta datagrama em caso de erro. 
o Identifica-se como destino do datagrama 
m Caso contrário, descarta o datagrama. 
o Entrega datagrama ao protocolo indicado 


m Processo de remontagem pode ser necessário. 





m Descarta fragmentos e gera mensagem de erro em caso de falha na remontagem. 






Tem espaço 
no buffer? 





ps Descarta o datagrama 
Mensagem erro ICMP D 


SIM { 


Armazena 
o datagrama 







Header 
Checksum 






t 


Destino 
correto? 













Datagrama 
completo? 


SIM { 
Entrega o datagrama 
protocolo superior 





Remonta o 
datagrama 


Figura 6.7 
Processamento na 
estacdo destino. 
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Processamento no roteador 


a Recebe e armazena datagrama 
m Descarta datagrama e gera mensagem de erro quando não possui buffer. 
o Verifica integridade do cabeçalho 
a Descarta datagrama em caso de erro. 
o Identifica-se como roteador intermediário. 
a Decrementa o TTL 
m Descarta datagrama e gera mensagem de erro quando o TTL atinge o valor 0. 
a Descobre rota para o destino 
ao Avalia a necessidade de fragmentação. 


m Descarta o datagrama e gera mensagem de erro se fragmentação é necessária 
e está desabilitada. 


a Envia o datagrama ou fragmentos 
m Entrega direta ao destino, se destino está na mesma rede física do roteador. 


m Entrega indireta a outro roteador, se destino está em uma rede física diferente 
daquela do roteador. 






Tem espaco 
no buffer? 


SIM { 
Armazena 
o datagrama 













Header 
Checksum 


i 







L 
Ea rta 
o Ea Crm >) 


Sinem] Descarta o EEE 
—>|m-=m-1] TTL=TTL-1 ae Ed erro ICMP 
SIM y NÃO 


Entrega o datagrama Consulta tabela a 
protocolo superior de rotas 
Cu) Descarta o datagrama 
Mensagem erro ICMP 


endereço 









SIM 


Envia o datagrama Crm) 
para o next-hop 
Figura 6.8 { 
Processamento 
no roteador 


intermediário. 





MTU suporta 
datagrama? 





au EE o 
EE 
SIM 
Descarta o datagrama 
— Mensagem erro ICMP Crm) 
Figura 6.9 
Processo de REN Pa os ) 







Don't fragment 
ligado? 





Zz 
> 
O 
iE 
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Protocolo ICMP 


Fundamentos: 
o Permite que estações e roteadores troquem informações de erro e controle. 
ao Define diversos tipos de mensagens. 
a Sinaliza situações anormais. 
o Permite a identificação de algumas informações operacionais. 
o Mensagens ICMP são encapsuladas em datagramas IP. 
a Cabeçalho ICMP. 
Principais mensagens ICMP: 
a Echo request 
a Echo reply 
m Testam se um destino está operacional e pode ser alcançado através da rede. 
a Destination unreachable 
a Sinaliza que não foi possível entregar ou rotear o datagrama. 
a Falta de rota para o destino. 
a Porta de destino “fechada”. 
a Fragmentação é necessária, mas o bit DF está ligado. 
o Redirect 
m Atua na otimização do roteamento. 
o Time exceeded 
m TTL expirou. 
= Tempo para a remontagem expirou. 
O protocolo Internet Control Message Protocol (ICMP) é usado pela implementação do pro- 


tocolo IP de estações e roteadores para trocar informações de erro e controle, sinalizando 


situações especiais por meio de seus diversos tipos de mensagens. 


Mensagens ICMP são diretamente encapsuladas em datagramas IP. Na Figura 6.10 notamos 
que cada mensagem possui um campo de tipo e um campo de código, que identificam as 


diversas mensagens existentes, e um campo de checksum (soma verificadora). 


1 2 3 


Identifier Sequence Number Figura 6.10 
e 
ate protocolo ICMP. 


O cabeçalho pode apresentar campos adicionais de acordo com o tipo de mensagem. 





Algumas mensagens contêm o cabeçalho e os primeiros 8 bytes do datagrama IP, respon- 
sável pela geração daquela mensagem, permitindo à estação de origem identificar algumas 
informações adicionais sobre o erro sinalizado. Mensagens do tipo Echo Request e Echo Reply 
contêm os campos Identifier e Sequence Number que permitem que a estação identifique as 


mensagens que foram perdidas e aquelas que foram respondidas. 


Figura 6.11 
Mensagem Redirect 
do protocolo ICMP. 


Vale ressaltar que mensagens ICMP nem sempre sinalizam apenas erros, mas também infor- 
mações operacionais e de controle. As mensagens Echo Request e Echo Reply são utilizadas 
para testar a conectividade entre duas estações e/ou roteadores na rede. Veremos mais 


detalhes de como elas são utilizadas quando estudarmos o comando ping. 


Em algumas situações, um roteador não consegue rotear ou entregar um determinado data- 
grama, como por exemplo: 

ao Falta de informações de roteamento. 

a Protocolo indicado no campo Protocol do datagrama IP não é suportado. 

a Não existe a porta indicada no segmento TCP ou datagrama UDP encapsulado. 


oa Fragmentação do datagrama é necessária, mas o bit Do not fragment do datagrama IP 


está habilitado. 


Nesses casos, o datagrama é descartado e o roteador envia a mensagem Destination 
unreachable (destino inatingível) para a origem do datagrama. Existem diferentes 
códigos para cada uma dessas situações e esses códigos são informados na mensagem 


Destination unreachable. 


O protocolo ICMP define a mensagem Redirect com o objetivo de otimizar o roteamento em 
uma situação particular. Por exemplo, considere a inter-rede apresentada na Figura 6.11. 


R1 





Nesse caso, podemos claramente perceber que a rota via R1 é a melhor alternativa para a 
estação E1 enviar um datagrama para qualquer estação da rede N2. No entanto, suponha 
que E1 está inadequadamente adotando uma rota via R2, que, por sua vez, roteia o data- 
grama para R1. Como R2 percebe que o datagrama foi recebido e encaminhado adiante 
usando a mesma interface de rede, R2 conclui que E1 poderia ter enviado o datagrama 
diretamente para R1. Assim, para otimizar o roteamento, R2 envia uma mensagem Redirect 


para E1, indicando que a melhor rota para a rede N2 é via R1. 


O roteador, antes de processar qualquer datagrama, primeiro decrementa o campo TTL 
(Time to Live - Tempo de Vida) ese o TTL atinge o valor 0, o roteador descarta o datagrama 
e envia uma mensagem ICMP à estação origem. Além disso, se o temporizador de frag- 
mentação expira antes da chegada de todos os fragmentos, a estação destino descarta 

os fragmentos recebidos e envia uma mensagem ICMP à estação origem. Nesses casos, a 


mensagem de erro enviada é denominada Time exceeded (Tempo excedido). 


O protocolo ICMP também possui um tipo especial de mensagem (Parameter Problem) 
utilizada para sinalizar o recebimento de datagramas IP que não estão em conformidade 
com o definido no protocolo. Por exemplo, datagramas em que o tamanho informado não 


corresponde ao seu tamanho real. Embora o protocolo ICMP seja usado diretamente pelo IP, 
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programas ping e traceroute exploram mensagens ICMP (Echo request, Echo reply, Time exce- 


eded e Destination unreachable) para prover algumas informações operacionais sobre a rede. 


Neste curso, vamos estudar apenas as mensagens mais usadas na prática. Para maiores 
informações sobre o formato detalhado das mensagens e seus vários tipos, sugerimos aos 
interessados uma consulta ao livro: COMER, Douglas E. Internetworking with TCP/IP - Volume I: 
Principles, Protocols and Architecture. 5th Edition. Prentice Hall, 2005. 


Comando ping 


Verificação de conectividade: 

a Envia um pacote Echo Request para o destino. 

a O destino responde com um pacote Echo Reply. 

a Informa o Round Trip Time (RTT) - tempo de ida e volta. 


Para testar se um determinado destino está operacional e pode ser alcançado através da 
rede, o comando ping envia mensagens Echo request (ICMP Tipo 8) para o destino especifi- 
cado. Após receber uma mensagem Echo request, o destino retorna uma mensagem Echo 
reply (ICMP Tipo 0). Se a resposta não é recebida, a estação origem pode concluir que o 
destino não está operacional ou não pode ser alcançado através da rede. 


Echo Request 





ICMP Tipo 8 

Echo Reply 

ICMP Tipo O Figura 6.12 
ORIGEM DESTINO Comando ping. 


Nesse processo, o ping calcula o tempo de resposta (Round Trip Time - RTT), dando uma ideia da 
proximidade daquele destino. Ao final da execução, o comando ping mostra o número de pacotes 
transmitidos e recebidos, o percentual de pacotes perdidos e o tempo total de execução. Além 


disso, o ping calcula o tempo de resposta mínimo (min), médio (avg) e máximo (max). 


O comando ping serve para verificar a conectividade entre origem e destino, não impor- 
tando se ambos estão na mesma rede ou não. 


Comando traceroute 


a Mostra o caminho do pacote até o destino. 

a Envia datagramas UDP para o destino. 

a Inicia com TTL=1 e vai incrementando até o destino. 
a Envia 3 datagramas para cada hop. 

a Cada roteador (hop) no caminho subtrai 1 do TTL. 


a Quando o TTL=0, o roteador envia uma mensagem de erro Time exceeded 
(ICMP tipo 11), informando seu endereço IP. 


a Aorigem calcula o RTT médio e imprime uma linha para cada hop que respondeu. 
a O destino responde com mensagem Destination unreachable (ICMP tipo 3). 


O comando traceroute tem como função descobrir o caminho entre duas estações ou 
roteadores. O programa traceroute utiliza uma combinação de mensagens Time exceeded e 
Destination unreachable para descobrir a rota entre duas estações ou roteadores. Para tal, o 


programa envia diversos datagramas UDP para portas inexistentes do destino desejado: 






o A primeira mensagem é enviada em um datagrama IP que possui TTL igual a 1, fazendo 
com que o primeiro roteador do caminho descarte o datagrama e retorne uma men- 


sagem Time exceeded. 


a Asegunda mensagem possui um TTL igual a 2, requerendo ao segundo roteador do 


caminho descartar o datagrama e gerar outra mensagem Time exceeded. 


a O processo termina quando o destino desejado recebe o datagrama UDP e envia para a 


origem uma mensagem Destination unreachable, pois a porta especificada não existe. 


A cada mensagem Time exceeded, o traceroute descobre um novo roteador intermediário 

no caminho até o destino. Como datagramas são independentes e podem seguir por rotas 
diferentes, os diversos datagramas UDP, encapsulados em datagramas IP, podem seguir por 
diferentes rotas. Assim, o traceroute não assegura que todos os roteadores intermediários 


identificados pertençam a uma única rota. 


Este comando se baseia no fato de que quando o campo TTL (Time To Live - Tempo de 
Vida) do datagrama IP atinge zero, o roteador não pode rotear o datagrama, mas precisa 
obrigatoriamente descartá-lo e enviar uma mensagem de erro Time exceeded (ICMP tipo 11), 
informando seu endereço IP. É assim que a origem fica sabendo o caminho que o data- 


grama está percorrendo. 


O datagrama UDP carrega um número de port improvável para o destino, de modo que, 
quando ele finalmente chega lá, o destino responde com uma mensagem de erro Port 
unreachable (ICMP tipo 3), ao invés da mensagem de erro Time exceeded. É assim que a 


origem fica sabendo que o destino foi atingido. 


RouterO Router1 Router2 


op1 hop2 h 








UDP TTL=1 
ICMP Tipo 11 
UDP TTL=2 
ICMP Tipo 11 
UDP TTL=3 
ICMP Tipo 11 
UDP TTL=4 
ICMP Tipo 3 


Figura 6.13 
Comando traceroute 
do Linux. 


Mecanismo do comando traceroute 


A Figura 6.13 mostra o mecanismo do comando traceroute na nossa rede de teste. Na figura 
está representado apenas um datagrama para cada hop, mas a aplicação envia 3 data- 


gramas idénticos para cada hop. 


Os 3 primeiros datagramas têm TTL=1 e são descartados pelo primeiro hop (router0), porque 


este subtrai 1 do TTL (1-1=0), com uma mensagem de erro Time exceeded (ICMP tipo 11). 


Os 3 seguintes têm TTL=2 e passam pelo primeiro hop (subtrai 1 do TTL: 2-1=1) e são descar- 


tados pelo segundo hop (router1), também com a mesma mensagem de erro. 
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Os 3 seguintes têm TTL=3 e passam pelo primeiro hop (subtrai 1 do TTL: 3-1=2), passam pelo 
segundo hop (subtrai 1 do TTL: 2-1=1) e são descartados pelo terceiro hop (router2), também 


com a mesma mensagem de erro. 


Finalmente, os 3 últimos passam por todos os hops porque têm TTL=4 e chegam ao destino 
ainda com TTL=1. Porém, a porta UDP de destino não existe no host de destino, que então 
gera uma mensagem de erro Destination unreachable (ICMP tipo 3). Essa descrição do 
mecanismo usado pelo comando traceroute é válida para o Linux, mas não para o Windows. 


Vamos analisar o mecanismo usado em cada caso a seguir. 
Exemplo de traceroute em Windows 


Configuração da estação 


a Considerações iniciais. 
a Endereço IP da estação de testes. 


o Gateway padrão. 


A seguir a listagem do comando ipconfig que mostra a configuração da estação que será 
usada para os testes. 


C:\>ipconfig 
Configuração de IP do Windows 
Adaptador Ethernet Conexão local: 
SUTILO DNS especiTico 0e conexao espa 


Endereco IPv6 de link local 
fe80::6964:d7b1:6170:4ae4%10 





Endereço ly o 2 6 6 vos © 6 eo o sas 8 BZ IES 100,130 
Maseeaira cle Suilo-P@Gle 5. . 6 6 0 6 6 O) 
Gateway Para. sv oo 6 6 o oo ow o cs o 8 IZ SO 


Informações importantes obtidas da listagem acima: 


1. Endereço IPv4 da estação: 192.168.100.130 


Este endereço deverá aparecer nos pacotes capturados durante os testes, que veremos a seguir. 


2. Gateway padrão: 192.168.100.1 


Este é o endereço do roteador que dá acesso à internet e é o primeiro hop da rede. 


a Servidor DNS para obtenção do endereço IP de destino. 

a Entrega indireta com tradução NAT. 

ao Primeiro hop: gateway padrão; último: destino final. 

a 3 roteadores intermediários (TTL vai até 4). 

Agora a listagem do comando traceroute para o sítio esr.rnp.br, a partir da unidade da 


ESR de Brasília. 


CoNDiraCerE esr rna or 


Figura 6.14 
Arquivo de captura 
Wireshark Windows. 


No. 


me 


OD Ci dy my há 


Time 


0 
0 
o 
0 
0. 
0 
o 
0 
0 
0. 


« 000000 
« 002869 
. 039777 
«041361 


044860 


«045775 
- 047073 
« 047920 
« 050354 


081264 


Rastreando a rota para esr.rnp.br [200.130.35.73] 


com no maximo 30 saltos: 
1 ms ms 
2 ms ms 
1 ms ms 
1 ms ms 
Rastreamento concluído. 


3 


4 











ms 192.168.100.1 
ms 200.130.26.254 
ms rt.pop-df.rnp.br [200.130.101.94] 


ms 200.130.35.73 


Informações importantes obtidas da listagem acima: 


O comando traceroute teve como destino o sítio da web: www.esr.rnp.br, que foi traduzido 


pelo servidor DNS (Serviço de Nome de Domínio) para o endereço IPv4: 200.130.35.73. 


Este será o endereço de destino dos pacotes que serão disparados pelo traceroute. 


Visto que o endereço da estação é um endereço privado (192.168.100.130) e o endereço de 


destino é um endereço público (200.130.35.73), que está em outra rede, podemos concluir: 


2.1. 


Haverá uma entrega indireta, passando por pelo menos um roteador intermediário; 


2.2. Haverá uma tradução NAT do endereço privado da estação, uma vez que o ende- 


reço de destino é um endereço público que está em algum lugar da internet. 


O primeiro hop, como não podia deixar de ser, é o gateway padrão da nossa rede: 


192.168.100.1, visto na listagem anterior de configuração. 


Temos 3 roteadores intermediários: 192.168.100.1 (gateway padrão), 200.130.26.254 e 


200.130.101.94; portanto, o pacote que chegará ao destino tem obrigatoriamente TTL=4. 


Da mesma forma que o primeiro hop é sempre o gateway padrão, o último hop é sempre 


o destino final, no nosso caso um servidor, e não um roteador. 


Note que essa análise preliminar é essencial para o entendimento dos pacotes capturados. 


O software Wireshark simplesmente mostra o conteúdo dos pacotes, não fazendo a inter- 


pretação do que está ocorrendo. Esse é o nosso trabalho. 


Captura de pacotes do primeiro hop 


Consulta ao servidor DNS (com sucesso) E 


3 pacotes Echo (ping) request para TTL=1. 


3 pacotes Time-to live exceeded. 


Consulta ao DNS reverso (sem sucesso). 


Vamos abrir o arquivo Trace Captura. pcap com o Wireshark e analisar os pacotes capturados 


durante a execução do comando traceroute. A tela com os primeiros 10 pacotes está 


mostrada na Figura 6.14. 


Sourc 
192. 
200. 
192. 
192. 
192. 
192. 
192. 
192. 
192. 
200. 


e 
168. 
130. 
168. 
168. 
168. 
168. 
168. 
168. 
168. 
130. 


100.130 
77.69 
100.130 
100.1 
100.130 
100.1 
100.130 
100.1 
100.130 
77.69 


Destination 
200. 
192. 
200. 
192. 
200. 
192. 
200. 
192. 
200. 
192. 


130. 
168. 
130. 
168. 
130. 
168. 
130. 
168. 
130. 
168. 


Protocol 


77.69 DNS 
100.130 DNS 
35.73 ICMP 
100.130 ICMP 
35.73 ICMP 
100.130 ICMP 
35.73 ICMP 
100.130 ICMP 
77.69 DNS 
100.130 DNS 


Length Info 


74 Standard query A www. esr.rnp.br 

299 standard query response A 200.130. 35.73 

106 Echo (ping) request id=0x0001, seq=1/756, Trl=1 

70 Time-to-live exceeded (Time to live exceeded in transit) 
106 Echo (ping) request id-0x0001, seq-2/512, ttl-1 

70 Time-to-live exceeded (Time to live exceeded in transit) 
106 Echo (ping) request id=0x0001, seq=3/768, TTl=] 

70 Time-to-live exceeded (Time to live exceeded in transit) 
86 standard query PTR 1.100.168.192.in-addr. arpa 

163 Standard query response, No such name 
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O pacote número 1 é uma consulta padrão ao servidor DNS (tipo A) para obter o endereço IP 
do nome: www.esr.rnp.br e o pacote número 2 é a resposta a essa consulta, informando que 


o endereço IP desejado é: 200.130.35.73. Obtido esse endereço, de agora em diante todos os 


pacotes serão disparados para esse destino. 


Por exemplo, o pacote 3 é um “Echo (ping) request” (mensagem Echo request - ICMP tipo 8) 
e o pacote 4 é um “Time-to-live exceeded” (mensagem Time exceeded - ICMP tipo 11), que 

é a resposta à mensagem anterior. Essa resposta é dada pelo gateway padrão, que é o 
primeiro roteador no caminho até o destino. Observe que o Wireshark informa, no pacote 
3, que o TTL=1. É importante destacar que, ao invés de enviar datagramas UDP ao destino, o 


comando tracert no Windows envia mensagens ICMP Echo request. 


Os pacotes 5 a 8 são a repetição dessas mesmas mensagens com TTL=1 (lembre-se de que o 


traceroute sempre envia 3 pacotes de cada vez). 


Já o pacote 9 é uma consulta ao servidor DNS reverso, ou seja, é uma consulta tipo PTR para 
obter o nome da máquina com endereço IP: 192.168.100.1 (no caso é o gateway padrão). Esse 
tipo de consulta é sempre feito para um servidor específico no dominio “arpa”. 


O pacote 10 informa que não há nome registrado para esse endereço IP. 


A consulta ao servidor DNS tipo A (dado um nome, obter o endereço IP), também chamada 
de “resolução de nome”, é um tipo de consulta pública cujo funcionamento é mandatório, 


sob pena de o referido sítio nunca ser acessado (quem lembra o IP do www.google.com?). 





Por outro lado, a consulta ao DNS reverso é opcional, porque o nome não é essencial para 
o acesso ao equipamento. O traceroute tenta obter o nome do roteador por uma questão 


meramente informativa. Se não conseguir, imprime somente o endereço IP. 


Demais pacotes 


a Pacotes 13 a 18 para TTL=2 - resposta dada pelo roteador seguinte. 
a Pacotes 25 a 30 para TTL=3 - resposta dada pelo terceiro roteador. 


o Pacotes 33 a 38 para TTL=4 - chegam até o destino final; a resposta não é mais 
“Time-to-live exceeded”; assim o traceroute fica sabendo que chegou ao destino. 


Os pacotes 13 a 18 repetem a mesma informação que os pacotes 3 a 8, agora para o TTL=2. 
Observe que o roteador que responde, nesse caso, é o seguinte ao gateway padrão no 
caminho até o destino: 200.130.26.254 (veja a listagem do comando traceroute). 


Os pacotes 25 a 30 repetem a mesma informação que os pacotes 3 a 8, agora para o TTL=3. 
Observe que, neste caso, o roteador que responde é o terceiro roteador no caminho até o 
destino: 200.130.101.94. O pacote 31 tenta obter o nome desse roteador, e o pacote 32 é a 
resposta bem-sucedida. O nome é: rt.pop-df.rnp.br. 


Os pacotes 33 a 38 repetem a mesma informação que os pacotes 3 a 8, agora para o TTL=4. 
Observe que neste caso quem responde é o destino final, com a mensagem “Echo (ping) 
reply” (mensagem Echo reply - ICMP tipo 0). Como o destino não é um roteador, ele não 
decrementa o TTL e simplesmente responde à mensagem “Echo (ping) request” (mensagem 
Echo resquest - ICMP tipo 8), como se estivesse recebendo um ping. Novamente, é impor- 
tante destacar que, ao invés de enviar como resposta uma mensagem ICMP Destination 
unreachable, o destino envia uma mensagem ICMP Echo reply. 


® O traceroute do Windows usa um mecanismo diferente do Linux para obter a rota até o 


destino: usa somente mensagens ICMP, como se fosse o ping, apenas ajustando o TTL. 


Exemplo de traceroute em Linux 


Vamos agora fazer a mesma análise para o Linux. A configuração da estação é a mesma. 


Mostramos a seguir a listagem do comando traceroute para o sítio ipv6.br. 
aluno@aluno-LE:~$ traceroute ipv6.br 

traceroute to ipv6.br (200.160.4.22), 30 hops max, 60 byte packets 

1 192.168.100.1 (192.168.100.1) 2.248 ms 2.439 ms 9.990 ms 

2 200.130.26.254 (200.130.26.254) 15.331 ms 16.599 ms 16.876 ms 

3 xe-2-0-0-2910-r0-df.bkb.rnp.br (200.143.255.169) 15.405 ms 15.629 ms 16.949 ms 


4 xe-3-1-1-3000-r0-rj.bkb.rnp.br (200.143.252.77) 27.937 ms xe-2-1-1-3000-r0-mg.bkb.rnp. 
br (200.143.252.81) 27.136 ms xe-3-1-1-3000-r0-rj.bkb.rnp.br (200.143.252.77) 30.320 ms 


5 xe-3-1-0-3000-r0-sp.bkb.rnp.br (200.143.252.73) 38.430 ms 39.088 ms xe-2-1-0-3000-r0- 
sp.bkb.rnp.br (200.143.252.69) 40.063 ms 


6 as22548.sp.ptt.br (187.16.217.2) 40.609 ms 28.587 ms 28.665 ms 

7 xe-5-1-0-0.core2.nu.registro.br (200.160.0.172) 29.296 ms 30.900 ms 31.354 ms 
8 ae0-0.ar4.nu.registro.br (200.160.0.250) 32.806 ms 33.315 ms 34.282 ms 

9 ipv6.br (200.160.4.22) 34.856 ms 35.413 ms 37.786 ms 

aluno@aluno-LE:~$ 


Informações importantes obtidas da listagem acima: 


1. O comando traceroute teve como destino o sítio da web: ipv6.br, que foi traduzido pelo 
servidor DNS (Serviço de Nome de Dominio) para o endereço IPv4: 200.160.4.22. Este será 


o endereço de destino dos pacotes que serão disparados pelo traceroute. 


2. Visto que o endereço da estação é um endereço privado (192.168.100.130) e o endereço de 
destino é um endereço público (200.160.4.22), que está em outra rede, podemos concluir: 


2.1. Haverá uma entrega indireta, passando por pelo menos um roteador intermediário. 


2.2. Haverá uma tradução NAT do endereço privado da estação, uma vez que o ende- 


reço de destino é um endereço público que está em algum lugar da internet. 


3. O primeiro hop, como não podia deixar de ser, é o gateway padrão da nossa rede: 


192.168.100.1, visto na listagem anterior de configuração. 


4. Temos 8 roteadores intermediários: 192.168.100.1 (gateway padrão), 200.130.26.254, 
200.143.255.169, 200.143.252.77, 200.143.252.73, 187.16.217.2, 200.160.0.172 e 
200.160.0.250; portanto, o pacote que chegará ao destino tem obrigatoriamente TTL=9. 


5. Da mesma forma que o primeiro hop é sempre o gateway padrão, o último hop é sempre 
o destino final, que no nosso caso é um servidor e não um roteador. 
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Vamos abrir o arquivo Trace Captura Linux.pcap com o Wireshark e analisar os pacotes cap- 
turados durante a execução do comando traceroute. A tela com os primeiros 10 pacotes está Figura 6.15 


mostrada na Figura 6.15. Arquivo de captura 
Wireshark Linux. 


No. Time Source Destination Protocol Length Info 

1 0.000000 192.168.100.130 200.130.77.69 ONS 67 Standard query A ipv6.br 

2 0.002295 200.130.77.69 192.168.100.130 DNS 215 Standard query response A 200.160.4.22 

3 0.003145 192.168.100.130 200.160.4.22 UDP 74 Source port: 46446 Destination port: traceroute 
4 0.003286 192.168.100.130 200.160.4.22 UDP 74 Source port: 35362 Destination port: 33435 
5 0.003372 192.168.100.130 200.160. 4.22 UDP 74 Source port: 40167 Destination port: 33436 
6 0.003450 192.168.100.130 200.160.4.22 UDP 74 source port: 55035 vestination port: 33437 
7 0.003527 192.168.100.130 200.160.4.22 UDP 74 Source port: 50434 Destination port: 33438 
R 0.003615 197.168.100.130 200.160.4.7? une 74 Source port: 37708 Nestinatioan port: 33439 
9 0.003691 192.168.100.130 200.160.4.22 UDP 74 Source port: 52094 Destination port: 33440 
10 0.003765 192.168.100.130 200.160.4.22 UDP 74 Source port: 57741 Destination port: 33441 


a Comando traceroute. a 


a Servidor DNS para obtenção do endereço IP de destino. 
o Entrega indireta, com tradução NAT. 

o Primeiro hop: gateway padrão. 

a Ultimo hop: destino final. 

o 8roteadores intermediários (TTL vai até 9). 


O pacote número 1 é uma consulta padrão ao servidor DNS (tipo A) para obter o endereço 
IP do nome: ipv6.br e o pacote número 2 é a resposta a essa consulta, informando que o 
endereço IP desejado é: 200.160.4.22. Obtido esse endereço, todos os pacotes de agora em 


diante serão disparados para esse destino. 


Por exemplo, os pacotes de número 3 até 18 usam o protocolo UDP com números de porta 
que não existem no destino (números de porta muito altos), de forma a forçar uma resposta 
de porta UDP inexistente no destino final. Mas como o TTL inicia em 1 e vai crescendo, chegam 
as mensagens de erro “Time-to-live exceeded” (mensagem Time exceeded - ICMP tipo 11) dos 


roteadores intermediários (por exemplo, os pacotes de número 19 e 20, entre outros). 


Já o pacote 51 é uma consulta ao servidor DNS reverso, ou seja, é uma consulta tipo PTR com 
o objetivo de obter o nome da máquina que tem o endereço IP: 200.143.255.169 (no caso é 
um roteador intermediário). Esse tipo de consulta é sempre feito para um servidor especi- 


fico no domínio “arpa”. E o pacote 52 informa o nome: xe-2-0-0-2910-r0-df.bkb.rnp.br. 


Essa sequência de pacotes se repete várias vezes, uma vez que foi necessário passar por 
8 roteadores intermediários no caminho até o destino final e o traceroute envia 3 pacotes 


para cada hop, com o mesmo TTL. 


Vamos agora analisar em detalhe a sequência de pacotes enviada pelo host 192.168.100.130 
para o destino 200.160.4.22, usando o protocolo UDP e que provocou igual sequência de 
respostas “Destination unreachable (Port unreachable)” (mensagem Destination unreachable 
- ICMP tipo 3). 


Vimos pela listagem do comando traceroute que o destino final estava no hop 9, portanto, os 
pacotes com TTL=9 (ou maior) chegaram até o destino final, porque passaram pelos 8 rotea- 


dores intermediários e, no destino final, provocaram a mensagem de erro ICMP acima referida. 


Para saber o TTL, precisamos selecionar o pacote na primeira janela do Wireshark, sele- 
cionar a linha do protocolo IP na janela imediatamente abaixo (segunda janela), clicar no 


icone do sinal “+” na primeira posição à esquerda da linha. 


Figura 6.16 
Resumo dos 
pacotes UDP 
enviados com TTL=9 
ou maior. 


Analisando a sequência de pacotes UDP, vemos que o pacote 72 é o primeiro com TTL=9, 
seguido pelos pacotes 73 e 74 também com TTL=9. Esses pacotes chegaram com certeza até 


o destino final, mas como a resposta demorou para voltar, o traceroute continuou emitindo 


pacotes UDP e aumentando o TTL, até que começaram a chegar as respostas do destino final. 


Consulta ao servidor DNS. 

Pacotes 3 a 18: protocolo UDP. 

m Mensagens de erro Time-to-live exceeded 
Pacote 51: consulta ao DNS reverso (com sucesso). 
Pacote 52: nome Xe-2-0-02910-r0-df.bkb.rnp.br. 
Sequência repetida várias vezes: 

m 8 roteadores intermediários. 

m 3 pacotes para cada hop com o mesmo TTL. 
TTL=9 ou acima chegam até o destino final. 

m Provocam a mensagem de erro Destination unreachable. 
Resumo dos pacotes com TTL = 9 ou maior. 

m Pacotes 72 a 80. 

m Pacotes 82, 91, 100. 

m Pacotes 102 a 105. 





Total: 16. 

Número TTL 
72a74 9 
75a77 10 
78 a 80 11 
82, 91, 100 12 
102 a 104 13 
105 | 14 


Total de pacotes com TTL=9 ou maior: 16. 


Resumo das mensagens de erro do destino final: 


Pacotes 92,94 a 97. 

Pacotes 99, 101, 107 e 108. 

Pacotes 110 a 116. 

Total: 16. 

Note que o TTL na resposta = 56 (64 - 8). 


Parâmetro -/ força o uso de mensagens ICMP Echo request e Echo reply. 
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Número TTL 


92 : 56 

94a97 i 56 

EA : E Figura 6.17 

107, 108 : 56 Resumo dos 
E pacotes com 

110 a 116 Es mensagens 
de erro ICMP. 


Esses 16 pacotes que chegaram com certeza até o destino final devem ter provocado igual 
número de mensagens de erro ICMP Destination unreachable (Port unreachable). 


Total de pacotes de resposta: 16. 


Note que em todos os pacotes o TTL = 56, porque por padrão, o pacote é enviado com 
TTL = 64 e passa por 8 roteadores intermediários (64 - 8 = 56). 


Se quiser que o traceroute do Linux use o mesmo esquema do Windows (somente mensa- 
gens ICMP Echo request e Echo Reply), use a opção -I na linha de comando. 


Resumindo: observe que os datagramas UDP são sempre enviados da estação origem 
192.168.100.130 para a estação destino 200.160.4.22. A estação origem usa a porta UDP 
46446 e outras portas de número alto nos pacotes seguintes. No entanto, o traceroute usa 
uma porta possivelmente inexistente no destino, que é incrementada a cada novo data- 
grama UDP. Nesse caso, a porta UDP de destino varia de 33434 (padrão traceroute) a 33473. 
Nos três primeiros datagramas UDP, o TTL é 1. Assim, o primeiro roteador do caminho 
(192.168.100.1) descarta esses datagramas, enviando uma mensagem Time exceeded para 
cada um deles. Nos últimos datagramas UDP com TTL=9 ou maior, a estação destino já foi 
alcançada. Nesse caso, como não existe um processo recebendo pacotes nas portas UDP 
33458 e acima, a estação destino descarta esses datagramas, enviando a mensagem Port 
unreachable, um subtipo da mensagem Destination unreachable, para cada um deles. É dessa 
forma criativa que o comando traceroute consegue mostrar o caminho pelo qual um data- 
grama passa da origem até o seu destino. 





Figura 6.18 
Rede da 
Atividade 6.1 


= Roteiro de Atividades 6 


Atividade 6.1 - Campo TTL 


Na figura mostrada a seguir, a estação E1 está gerando datagramas IP com TTL igual a 2. 
Na operação normal da rede, E1 envia datagramas para E2 via o roteador R3. No entanto, 
quando a estação E1 perde a conectividade com o roteador R3, ela envia datagramas para 


E2 via o roteador R1. 





1. Os datagramas são entregues à estação E2 em ambos os casos? Explique. 














2. Alguma mensagem de erro é gerada? Qual? 




















3. Quando e por que a mensagem de erro é gerada? Para quem a mensagem de erro é enviada? 
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Atividade 6.2 — Funcionamento do TTL 


1. Inicie o Virtual Box e selecione a opção “Open a Virtual Machine”, selecione a máquina 


virtual “vcore-4.2" no diretório que o instrutor indicar, e inicie esta maquina virtual. 


2. Aguarde a carga completa da máquina virtual CORE. Essa máquina virtual possui ins- 


talado um simulador de protocolos de roteamento, que usaremos de agora em diante. 


Execute o simulador CORE. 


3. Selecione “File” no menu, selecione a opção “Open” e localize o diretório onde se encontra 


Figura 6.19 


a rede: “Rede Atividade6 2.imn”, seguindo a orientação do instrutor. Rede da 


4. Arede deverá ser igual à Figura 6.19. 


R1 
EASY eth1 
ie by ™10.0.2.1/24 
ethO 
10.0.0.2/24 
e1 
e0 4 4 Redeo 
e2 
etho 
10.0.0.1/24 
ste eth1 


E Sm 10.0.1.1/24 


R3 


Atividade 6.2. 


etho 
10.0.2.2/24 


eth1 
10.0.1.2/24 


> ae etho 
ma 10.0.1.10/24 





5. Os endereços IPv4 já estão configurados, conforme mostrado na figura. Há 3 redes físicas 


representadas pelos switches RedeO, Rede1 e Rede2. Cada rede física tem um prefixo de 


rede diferente, conforme a Figura 6.20. 
Rede Endereço de rede 
RedeO 10.0.0.0/24 10.0.0.1 
Redet 10.0.1.0/24 10.0.1.1 


Rede2 : 10.0.2.0/24 E 


Gateway padrão 


ET 


: E2 


Nome PC Endereço PC 
É 10.0.0.10/24 
: Figura 6.20 
: 10.0.1.10/24 Endereços IPv4 
: da rede da 
i j Atividade 6.2. 


6. O modo inicial de operação do simulador é o Modo de Edição. Este modo é utilizado para 


desenhar a rede e configurar o endereçamento IPv4. Para efetivamente executar os 


protocolos de roteamento e as aplicações, é necessário iniciar o experimento, que pode 


ser feito de duas maneiras: 


o 


a Clicando no ícone 


a Selecionando no menu superior a opção Experiment/Start. 


a esquerda na barra de ferramentas; 


No Modo de Experimento não é possível fazer edição da topologia da rede (note a barra de 
ferramentas modificada). Aguarde até que toda a rede seja iniciada, até desaparecerem os 


colchetes vermelho/verde em cada nó da rede. 


7. Vamos testar o comando ping com TTL=2 da estação E1 para a estação E2. Siga o seguinte 


procedimento: 


a Aponte com o mouse para E1, clique no botão direito e selecione a opção Shell window/bash. 


No console do E1 digite o comando ping para E2: 
root@E1:/tmp/pycore.39156/El.conf# ping -c 2 -t 2 10.0.1.10 
O resultado deve ser semelhante ao listado a seguir: 

PING 10.0.1.110 (10.0.1.110 Sots) byres oF datas, 

64 bytes from 10.0.1.10: icmp req=1 ttl=2 time=15.4ms 

64 bytes from 10.0.1.10: icmp_req=2 ttl=2 time=1.00ms 


==> 100.10 ping statistics === 





2 packets transmitted, 2 received, 0% packet loss, time 1013ms 
rtt min/avg/max/mdev = 1.009/8.227/15.446/7.219 ms 
root@E1:/tmp/pycore.39156/E1.conf# 


Com TTL=2 funcionou, porque a rota seguida pelos datagramas de E1 para E2 passa por 
apenas um roteador: R3. Para confirmar isso, vamos executar o comando traceroute no 


console do E1. O resultado deve ser semelhante ao listado a seguir: 
root@E1:/tmp/pycore.39156/El.conf# traceroute -n 10.0.1.10 
traceroute to 10.0.1.10 (10.0.1.10), 30 hops max, 60 bytes packet 
1 10.0.0.1 (10.0.0.1) 1.185 ms 0.485 ms 0.166 ms 
2 10.0110 (OO AO) 20,983 ms 1,523 ims 0-370 ims 
root@E1:/tmp/pycore.39156/E1.conf# 


A opção “-n” evita a consulta ao servidor DNS para resolução de nomes. Como não existe servidor 
DNS configurado, o comando aguarda o “timeout” do DNS e a execução fica muito demorada. 


8. Vamos forçar a rota pelo roteador R1. Para isso, simplesmente mudaremos a tabela de 


rotas da estação E1. Para ver a tabela de rotas da estação E1, digite o comando a seguir. 


rootQGEl:/tmp/pycore.39156/El.conff route -n 


Kernel IP routing table 


Destination Gateway Genmask Flags Metric Ref Use Iface 
10.0.0.0 0.0.0.0 255 259.2550) dl) 0 0 0 etho 
ORORORG ORO ROR 0.0.0.0 UG 0 0 0 etho 


root@E1:/tmp/pycore.39156/E1.conf# 
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Para alterar a rota padrão da estação E1, vamos excluir a rota padrão pelo roteador R3 e 
incluir uma rota padrão pelo roteador R1. Siga o seguinte procedimento: 


root@E1:/tmp/pycore.39156/E1.conf# route del default gw 10.0.0.1 
root@E1:/tmp/pycore.39156/E1.conf# route add default gw 10.0.0.2 
root@E1:/tmp/pycore.39156/E1.conf# route -n 


Kernel IP routing table 





Destination Gateway Genmask Flags Metric Ref Use Iface 
10.0.0.0 ORURORO 295.259.2550  lW 0 0 0 etho 
0.0.0.0 MOROMONA 0.0.0.0 UG 0 0 0 etho 


root@E1:/tmp/pycore.39156/E1.conf# 

Pronto. Agora a rota padrão de E1 aponta para o roteador R1. 

9. Repita o comando ping com TTL=2, conforme a seguir. 
rooteEl:/tmp/pycore.39156/El.conff ping -c 2 -t 2 10.0.1.10 
PING 10.0.1.10 (10.0.1.10) 56(84) bytes of data. 

From 10,0.2:2 icmp seqsi Time to live exceeded 


From 10.0.2.2 icmp_seq=2 Time to live exceeded 





=== IG 110 ping Stacisties === 


2 packets transmitted, 0 received, +2 errors, 100% packet loss, 
time 1005ms 


root@E1:/tmp/pycore.39156/E1.conf# 


Q) Observe que foi o roteador R2 que enviou as mensagens de erro. 


10. Para confirmar, repita o mesmo comando, agora com TTL=3. 


root@E1:/tmp/pycore.39156/E1.conf# ping -c 2 -t 3 10.0.1.10 
PING 10.0.1.10 (10.0.1.10) 56(84) bytes of data. 

64 bytes from 10.0.1.10: icmp req=1 ttl=3 time=14.0ms 

64 bytes from 10.0.1.10: icmp_req=2 ttl=3 time=1.3/ms 

=== 100.1.10 ping Statistics === 

2 packets transmitted, 2 received, 0% packet loss, time 1013ms 
rtt min/avg/max/mdev = 1.376/7.712/14.049/6.337 ms 


root@E1:/tmp/pycore.39156/E1.conf# 


Funcionou, conforme mostrado acima. Finalmente, use o comando traceroute para confirmar 


a rota dos datagramas. 
root@E1:/tmp/pycore.39156/El.conf# traceroute -n 10.0.1.10 
traceroute to 10.0.1.10 (10.0.1.10), 30 hops max, 60 bytes packet 
1 10.0.0.2 (10.0.0.2) 0.976 ms 0.213 ms 0.143 ms 
2 100.202 (110.0.2.2) 0177 iis 0-172 me 0.203 ms 
3 10.0.1.10 (10.0.1.10) 0.466 ms 0.340 ms 0.302 ms 


root@E1:/tmp/pycore.39156/E1.conf# 


Atividade 6.3 - Remontagem no destino 


O processo de fragmentação de datagramas pode ocorrer em diversos roteadores interme- 
diários. Porém, o processo de remontagem ocorre somente no destino final. Identifique e 


comente possíveis vantagens e desvantagens dessa abordagem. 











Atividade 6.4 - Descobrindo a MTU 


Uma determinada rede física limita o tamanho máximo do quadro a 1500 bytes, sendo 
100 bytes de cabeçalho e 1400 bytes de dados. Qual a MTU dessa rede? Qual o maior data- 
grama IP que pode ser encapsulado em um quadro dessa rede? Qual a maior quantidade de 


dados que um datagrama IP pode transportar nessa rede? 

















Atividade 6.5 — Descobrindo tamanhos de datagramas 


Um determinado datagrama IP possui Total length e Hlen iguais a 1500 e 8, respectivamente. 


1. Qual o tamanho total deste datagrama em bytes? 

















2. Qual o tamanho do cabeçalho deste datagrama em bytes? 

















Ñ capítulo 6- Roteiro de Atividades 


269 


3. Ocampo Options é utilizado? 

















Atividade 6.6 — Fragmentação 


Na figura a seguir, considere que a estação E1 envia dois datagramas para a estação E2. 
Esses datagramas possuem 500 e 200 bytes, incluindo o cabeçalho de 20 bytes. 


OS HO fe 


MTU=500 MTU=200 MTU=500 


1. Afragmentação é necessária? 

















2. Em caso afirmativo, adotando o esquema da figura acima, apresente o datagrama original 
e os respectivos fragmentos. 
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Roteamento 










Apresentar os conceitos básicos de roteamento, descrever os protocolos de 
roteamento RIP, OSPF e BGP, apresentando suas características principais e 


sua configuração básica. 





Roteamento em redes IP e conceitos básicos de protocolos de roteamento. 


SO]9IU09 


Este capitulo trata de roteamento em redes IP e explora os conceitos basicos de protocolos 


de roteamento, descrevendo os protocolos básicos de maneira simplificada, pois não é obje- 


tivo deste curso tratar em detalhes o roteamento. 


Roteamento TCP/IP 


o Inter-rede TCP/IP 





m Composta por um conjunto de redes físicas interconectadas por roteadores. 
a Roteador 

m Roteia datagramas entre essas redes. 

m Recebe datagramas nas várias interfaces. 

a Escolhe rotas através de outras interfaces. 

m Encaminha datagramas através das interfaces selecionadas. 
o Roteamento 


m Processo de escolha das rotas para envio dos datagramas, permitindo que eles 





alcancem seus destinos através de diversas redes e roteadores intermediários. 


Sabemos que a estrutura de interconexão de inter-redes TCP/IP é composta por um con- 
junto de redes físicas interconectadas por roteadores. Nessa estrutura, o papel dos rotea- 
dores é interconectar as redes físicas e rotear datagramas IP entre essas redes. Em outras 
palavras, um roteador é capaz de receber datagramas nas suas várias interfaces de rede, 
escolher rotas através de interfaces conectadas às outras redes físicas e, por fim, encami- 
nhar esses datagramas através dessas interfaces selecionadas. Por exemplo, na Figura 7.1, 
quando a estação E1 deseja enviar datagramas para a estação E9, ela roteia os datagramas 
para o roteador R3, através da interface conectada à rede N1. Por sua vez, R3 entrega direta- 


mente os datagramas para a estação E9 através da interface conectada à rede N5. 
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Os roteadores não proveem conexão direta entre todas as redes físicas. Consequentemente, 
para alcançar um determinado destino, pode ser necessário encaminhar os datagramas 
através de diversos roteadores e redes intermediárias. Por exemplo, na Figura 7.1, data- 
gramas enviados da estação E1 à estação E8 devem ser encaminhados através dos rotea- 
dores R3 e R4, sendo, desta forma, transmitidos nas redes N1, N5 e N4. 


Além disso, podem existir diversas rotas alternativas para encaminhar os datagramas entre 
alguns pares de estações. Por exemplo, quando a estação E1 deseja transmitir datagramas 
para a estação E5, os roteadores R1 e R3 se apresentam como possíveis rotas alternativas 
até o destino. Portanto, E1 pode encaminhar os datagramas para R1 ou R3 através da 
interface conectada à rede N1. Com base nisso, podemos definir o processo de roteamento 
como sendo a escolha dos caminhos (rotas) a serem usados para enviar os datagramas, de 
modo a permitir que alcancem seus respectivos destinos finais, possivelmente através de 
diversas redes e roteadores intermediários. Dito de outra forma, o processo de roteamento 
determina a rota que cada datagrama deve seguir para alcançar a estação destino, indicada 
no cabeçalho do datagrama. 


É importante lembrar que roteadores são também conhecidos como gateways ou sistemas 


intermediários, na família de protocolos TCP/IP. Roteadores não são necessariamente equi- 


pamentos especializados na função de roteamento, mas podem ser estações multihomed 


que possuem a função de roteamento configurada. 





Para realizar o processo de roteamento, as implementações do protocolo IP devem ser 
projetadas levando em consideração diversos conceitos associados à função de roteamento, 
bem como alguns componentes de software. Neste capítulo, cada um desses conceitos e 
componentes será detalhado. 


Algoritmo de roteamento 


a Procedimento de tomada das decisões de roteamento para cada datagrama. 


a Implementado em todos os roteadores e estações da inter-rede. 


al 


Gateway 


Sinônimo de roteador 
na arquitetura 

TCP/IP. Em outras 
arquiteturas de redes, 
um gateway é um 
dispositivo (hardware 
ou software) que 
converte mensagens 
de um protocolo em 
mensagens de outro 
protocolo. 


Estações convencionais 
com várias conexões 
físicas. 


Figura 7.1 
Inter-rede TCP/IP. 


Algoritmo 
de roteamento 


Conjunto de regras ado- 
tadas pelo protocolo IP 
para descobrir a melhor 
rota até o destino final 
de cada datagrama. 


a Encaminha os datagramas até seus respectivos destinos finais. 


L_ 


a Descobre a melhor rota até o destino final de cada datagrama. 


Para rotear os datagramas, as implementações do protocolo IP adotam um algoritmo de 
roteamento bem definido e conhecido, cuja finalidade é tomar as decisões de roteamento 


para cada datagrama, encaminhando-o ao seu destino final. Portanto, o objetivo do algoritmo 
de roteamento é descobrir a melhor rota até o destino final de cada datagrama. Obviamente, 
todos os roteadores implementam o algoritmo de roteamento, pois estão diretamente envol- 


vidos nesse processo. Além deles, as estações também tomam decisões de roteamento. 


No exemplo em que a estação E1 envia datagramas à estação E5, E1 deve tomar decisões de 
roteamento, escolhendo se encaminha os datagramas através do roteador R1 ou R3, pois 
cada um deles provê uma rota possível para E5. Portanto, da mesma forma que os roteadores, 


todas as estações devem implementar o algoritmo de roteamento. 


O algoritmo de roteamento adotado na arquitetura TCP/IP é diferente para cada arquitetura 
de endereçamento (classful e classless). Mais à frente, discutiremos os algoritmos de rotea- 


mento adotados nas duas arquiteturas de endereçamento. 


Métricas de roteamento 


Parâmetros adotados pelo algoritmo de roteamento para selecionar as melhores rotas. a 
a Comprimento da rota. 
o Retardo. 

a Confiabilidade. 

o Taxa de transmissão. 
o Carga. 


a Tamanho do datagrama. 





ao Tipo de serviço. 


Métricas são parâmetros qualitativos e operacionais adotados por um algoritmo de rote- 
amento para definir a melhor rota a ser usada, preferindo uma rota específica a outras 
possíveis. Como podem existir múltiplas rotas para um determinado destino, o algoritmo 
de roteamento deve utilizar parâmetros qualitativos para definir a melhor rota a ser usada. 
Idealmente, o algoritmo de roteamento deve considerar alguns parâmetros operacionais da 
rede, evitando a seleção de rotas que encaminham os datagramas através de porções da 


rede que estão congestionadas ou falhando. 


Os parâmetros qualitativos e operacionais adotados por um algoritmo de roteamento são 
denominados métricas de roteamento. Diversas métricas podem ser usadas pelos algo- 
ritmos de roteamento: 

a Comprimento da rota - número de roteadores ao longo do caminho. 

o Retardo - tempo necessário para os bits transmitidos alcançarem o destino. 

o Confiabilidade - probabilidade de ocorrência de erros de transmissão. 

o Taxa de transmissão - número de bits que podem ser transmitidos por unidade de tempo. 
ao Carga - percentual de utilização dos enlaces. 

oa Tamanho do datagrama (MTU) - pode ser usado para evitar a fragmentação. 


o Tipo de serviço requerido - define a importância das demais métricas de roteamento 


na seleção da rota. 
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No entanto, as implementações dos algoritmos de roteamento são menos sofisticadas e, 
geralmente, selecionam rotas baseadas em um subconjunto reduzido dessas métricas de 


roteamento, ou apenas uma única métrica. 


Métrica da rota 





a Número inteiro não negativo que indica a qualidade da rota. 
o Derivada das métricas de roteamento. 
a Algoritmos de roteamento adotam um número reduzido de métricas de roteamento. 


a Métricas de roteamento são aplicadas a uma equação bem definida, gerando a 
métrica ou custo da rota. 


o Quanto menor a métrica, melhor a rota. 

As métricas de roteamento adotadas são aplicadas a uma equação bem conhecida, gerando 
o conceito de custo ou métrica da rota. Na prática, a métrica de uma rota é apenas um 
número inteiro não negativo que indica a qualidade da rota. Consequentemente, adotando a 


perspectiva de custo, quanto menor a métrica de uma rota, então melhor será esta rota. Por 
exemplo, uma rota de custo 5 é melhor que outra rota de custo 10. 


Portanto, com base nas métricas das rotas possíveis, o algoritmo de roteamento toma as 
decisões de roteamento para cada datagrama. Vale ressaltar que existe uma distinção entre 
métricas de roteamento e métricas de rotas. As métricas de roteamento são os parâmetros 
qualitativos ou operacionais usados para derivar as métricas (custos) das rotas. No entanto, 
muitas vezes, esses termos são usados com o mesmo significado, principalmente quando 
uma única métrica de roteamento é usada para derivar a métrica das rotas. 


Resumo 


Após receber um datagrama, o algoritmo de roteamento identifica as possíveis rotas para 
o destino do datagrama, avalia as métricas associadas a cada uma dessas rotas e, então, 
seleciona a rota de menor métrica. 


Tabela de roteamento 


a Mantém informações de roteamento para todas as redes físicas da inter-rede. a 
a Descreve a topologia geral da inter-rede. 
o Identifica rotas para todos os destinos. 
a Sinaliza os custos das rotas, provendo a noção de melhor rota para cada destino. 
a Direciona as decisões de roteamento realizadas pelo algoritmo de roteamento. 
o Existe em todos os roteadores e estações da inter-rede. 
a Adota um modelo de roteamento baseado em redes. 
m Mantém rotas que apontam para prefixos de rede e não para estações individuais. 
m Reduz a quantidade de informações armazenadas. 
a Melhora a eficiência do roteamento. 
m Torna o tamanho da tabela dependente do número de redes, mas independente 


do número de estações. 


Estrutura de dados que mantém informações que descrevem a topologia geral da inter-rede, 


identificando rotas para todos os possíveis destinos e a melhor forma de alcançá-los. Para ser 


capaz de rotear corretamente os datagramas, os algoritmos de roteamento dos roteadores 
e estações precisam conhecer a topologia geral de toda a inter-rede, e não apenas das redes 
físicas às quais estão diretamente conectados. Assim, os algoritmos de roteamento precisam 
manter informações de roteamento para todas as redes físicas que compõem a inter-rede 
TCP/IP. Essas informações de roteamento são armazenadas na tabela de roteamento. 


A noção de melhor rota para cada destino é sinalizada nos custos das respectivas rotas 
possíveis, derivados a partir das métricas de roteamento adotadas. Assim, as tabelas de 


roteamento direcionam todas as decisões realizadas pelos algoritmos de roteamento. 


Em cada roteador ou estação, sempre que a camada de rede precisa enviar datagramas, o 
algoritmo de roteamento consulta a tabela de roteamento para descobrir a rota a ser adotada 
para encaminhar cada datagrama. Portanto, considerando que roteadores e estações imple- 


mentam algoritmos de roteamento, concluímos que ambos possuem tabelas de roteamento. 


É importante lembrar que os esquemas de endereçamento pressupõem que todas as inter- 
faces conectadas a uma rede física compartilham um prefixo de rede, sub-rede ou bloco. 
Essa característica permite que as tabelas de roteamento possuam apenas informações 


sobre os prefixos de rede, ao invés de informações sobre estações individuais. 


Portanto, a arquitetura TCP/IP adota um modelo de roteamento baseado em redes, ao invés 
de estações. Em outras palavras, as rotas das tabelas de roteamento apontam para as redes, 
e não para as estações individuais. Essa abordagem torna mais eficiente o roteamento, pois 


reduz sensivelmente a quantidade de informações mantidas na tabela de roteamento. 


Considerando o modelo de roteamento baseado em redes, podemos concluir que o 
tamanho da tabela de roteamento depende da quantidade de redes físicas e/ou blocos 
que compõem a inter-rede, variando à medida que redes e/ou blocos são acrescentados 
ou removidos. Por outro lado, o tamanho das tabelas de roteamento é independente do 


número de estações existentes na inter-rede. 


Protocolo de roteamento 

a Mecanismo que implementa a atualização automática das tabelas de roteamento nos a 
roteadores. 

o Permite a definição de tabelas completas e consistentes. 


o Atualizações são realizadas a partir das informações de roteamento propagadas e 


trocadas entre roteadores. 
ao Propagações sinalizam mudanças operacionais das várias redes físicas. 
a Diversos protocolos são padronizados: 
m RIP (Routing Information Protocol). 
m OSPF (Open Shortest Path First). 
m BGP (Border Gateway Protocol). 
a Características operacionais diferenciam os protocolos de roteamento: 
m Número de caminhos. 
m Propagação das rotas. 
a Organização estrutural. 


a Hierarquia de roteamento. 
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Já vimos que os algoritmos de roteamento adotam métricas de roteamento para derivar 
os custos das várias rotas possíveis. Nesse processo, as métricas de roteamento permitem 
que os algoritmos de roteamento evitem porções da rede congestionadas ou com falha. 
No entanto, considerando que as condições operacionais das várias redes físicas podem 
variar a cada momento, as métricas de roteamento devem ser atualizadas para refletir as 
mudanças ocorridas na inter-rede. 


Como as tabelas de roteamento mantêm os custos das várias rotas, essas tabelas devem, 
consequentemente, ser sempre atualizadas para refletir as mudanças na situação opera- 
cional das várias redes físicas. Observe que mudanças no conteúdo das tabelas de rotea- 


mento modificam os caminhos que os datagramas devem seguir. 


Para atualizar as tabelas de roteamento, certo grau de cooperação dinâmica é necessário 
entre os roteadores. Em particular, roteadores devem trocar informações de roteamento 
que sinalizam as mudanças operacionais das várias redes físicas. Para tal, protocolos especí- 
ficos devem ser usados para viabilizar a propagação e a troca de informações de roteamento 
entre roteadores. Tais protocolos são denominados protocolos de roteamento. 


Em resumo, podemos definir um protocolo de roteamento como um mecanismo que 
implementa a atualização automática das tabelas de roteamento nos diversos roteadores. 
As atualizações são realizadas a partir das informações de roteamento trocadas entre os 
roteadores, permitindo a definição de tabelas completas e consistentes. Por tabelas com- 
pletas, entende-se as que possuem rotas para todos os possíveis destinos. Por tabelas con- 
sistentes, entende-se as que possuem rotas válidas que consideram a situação operacional 
atual das várias redes físicas. 


Existem diversos protocolos de roteamento padronizados na arquitetura TCP/IP. Dentre 
esses, os protocolos RIP (Routing Information Protocol), OSPF (Open Shortest Path First) e 
BGP (Border Gateway Protocol) são os principais, por serem os mais adotados na prática. 
Vale ressaltar que o objetivo aqui não é o de estudar e avaliar detalhadamente os protocolos 
de roteamento padronizados na arquitetura TCP/IP, mas apenas identificar as principais 


características operacionais que os diferenciam. 


Número de caminhos 


a Caminho único a 


a Instala uma única rota para cada destino. 
a Múltiplos caminhos 
a Instala, quando possível, diversas rotas para cada destino. 
Os protocolos de roteamento podem inserir diferentes rotas para um mesmo destino na 
tabela de roteamento: 
a Protocolo de caminho único - insere uma única rota para cada destino 
(exemplo: protocolo RIP). 


a Protocolo de múltiplos caminhos - insere, quando possível, diversas rotas para cada destino 
(exemplo: protocolo OSPF). 


Propagação de rotas 





a Vetor-distância 
m Periodicamente, envia informações de roteamento aos roteadores vizinhos. 


m Propagações são realizadas de forma independente das mudanças operacionais. 


o Estado de enlace 


m Envia a todos os roteadores informações sobre as redes físicas (enlaces) direta- 


mente conectadas. 


m Novas propagações somente são realizadas após mudanças operacionais nos enlaces. 


Os mecanismos de propagação de rotas também diferenciam os diversos protocolos de 


roteamento. Em termos gerais, existem dois mecanismos de propagação: 


o Vetor-distância (distance-vector) - este tipo de protocolo envia, periodicamente, infor- 
mações da tabela de roteamento apenas aos roteadores vizinhos, independentemente da 
ocorrência ou não de mudanças operacionais nas redes físicas (exemplo: protocolo RIP). 


o Estado de enlace (link-state) - este tipo de protocolo, inicialmente, propaga a todos os 
roteadores da inter-rede, informações sobre as redes físicas (enlaces) diretamente conec- 
tadas e, posteriormente, realiza novas propagações somente após mudanças no estado 


destes enlaces (exemplo: protocolo OSPF). 


Organização estrutural 


a Estrutura plana 
m Roteadores desempenham o mesmo papel, realizando as mesmas funções. 
a Estrutura hierárquica 
m Roteadores são organizados de forma hierárquica, desempenhando diferentes papéis. 
m Função de cada roteador depende de sua localização física na inter-rede. 
Alguns protocolos de roteamento definem diferentes funções para os roteadores, de acordo 


com a localização física desses roteadores dentro da inter-rede. Disso derivam, por consequ- 


ência, diferentes organizações estruturais: 


o Estrutura plana - adotada por um protocolo quando todos os roteadores desempenham 


o mesmo papel (exemplo: protocolo RIP). 


o Estrutura hierárquica - adotada por um protocolo quando os roteadores são organi- 
zados hierarquicamente, desempenhando diferentes papéis nessa hierarquia (exemplo: 
protocolo OSPF). 


Hierarquia de roteamento 


o IRP (Interior Routing Protocol) 
a Protocolo de roteamento adotado dentro de sistemas autônomos. 
o ERP (Exterior Routing Protocol) 


a Protocolo de roteamento adotado entre sistemas autônomos. 


Para organizar e administrar a propagação de rotas na internet, um conjunto de redes 
controladas por uma única autoridade administrativa é chamado de Sistema Autônomo 
(AS - Autonomous System). Dessa forma, a internet é composta por um conjunto de 
sistemas autônomos interconectados. Dentro de um determinado sistema autônomo, a 
autoridade administrativa possui autonomia para selecionar o protocolo de roteamento a 
ser adotado. Logo, podemos classificar os protocolos de roteamento de acordo com a sua 


área de abrangência: 


a Protocolos de roteamento interior (IRP - Interior Routing Protocol) - protocolos de roteamento 


que podem ser adotados dentro de sistemas autônomos (exemplo: protocolos RIP e OSPF). 
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a Protocolos de roteamento exterior (ERP - Exterior Routing Protocol) - protocolos de rote- 
amento que podem ser adotados entre sistemas autônomos (exemplo: protocolo BGP). 


Propagação de máscaras 
ao Protocolo classful 
m Não inclui as máscaras de rede quando propaga informações de roteamento. 


o Protocolo classless 


a Inclui as máscaras de rede quando propaga informações de roteamento. 


Por fim, da mesma forma que os esquemas de endereçamento, os protocolos de rotea- 
mento também são classificados em protocolos classful e classless. A Única diferença é a 
capacidade de propagar as máscaras de rede: 


a Protocolos classful - não propagam as máscaras de rede (exemplo: protocolo RIPv1). 


a Protocolos classless - propagam as máscaras de rede (exemplo: protocolo OSPF e versão 2 
do protocolo RIP). 


Principais protocolos de roteamento na arquitetura TCP/IP 


o RIP (Routing Information Protocol) - protocolo de roteamento tipo vetor-distância que 
propaga, periodicamente, informações de roteamento aos roteadores vizinhos, indepen- 


dentemente de ocorrerem ou não mudanças operacionais nas redes físicas. 


a OSPF (Open Shortest Path First) - protocolo de roteamento tipo estado de enlace que 
propaga as informações dos enlaces de rede para todos os roteadores, apenas na iniciali- 


zação ou após mudanças no estado dos enlaces. 


o BGP (Border Gateway Protocol) - protocolo de roteamento tipo exterior usado para propagar 


informações sobre o alcance das redes que compõem os diversos sistemas autônomos. Sistema autônomo 
Conjunto de redes 
Representação de rotas controladas por uma 
única autoridade 
a Modelo de roteamento administrativa, que 
possui autonomia para 
m A arquitetura TCP/IP adota o modelo de roteamento passo-a-passo (hop-by-hop). selecionar o protocolo 


s n ; . de roteamento interno. 
m Estações de uma mesma rede podem enviar datagramas diretamente entre si. 


m Estações de redes distintas devem enviar datagramas ao próximo roteador do 
caminho (next-hop). 


m Datagramas são encaminhados de um roteador para outro, até que possam ser 
entregues diretamente. 


o Tabela de roteamento 
a Rotas indicam apenas o próximo roteador (next-hop) do caminho até a rede de destino. 
m Roteadores e estações não conhecem o caminho completo até o destino. 
m Rotas são representadas por pares (N, R). 
a N:endereço da rede de destino. 
a R: endereço do próximo roteador. 
m O próximo roteador R deve residir em uma rede diretamente conectada. 


a Para redes diretamente conectadas, R é apenas uma indicação de entrega direta. 
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Figura 7.2 
Tabela de 
roteamento. 


Na arquitetura TCP/IP, a camada de rede adota 0 modelo de roteamento hop-by-hop 
(passo-a-passo), técnica de roteamento na qual a estação origem e cada roteador interme- 
diário entregam o datagrama ao próximo roteador do caminho, até que algum deles possa 


entregar o datagrama diretamente à estação destino. 


Nesse modelo, se as estações origem e destino estão conectadas na mesma rede física, o 
algoritmo de roteamento da estação origem encaminha o datagrama diretamente à estação 
destino. No entanto, se as estações origem e destino estão conectadas a redes físicas dis- 
tintas, o algoritmo de roteamento da estação origem roteia o datagrama ao próximo roteador 
(next-hop) do melhor caminho até o destino. Por sua vez, esse roteador intermediário assume 
a responsabilidade de continuar encaminhando o datagrama ao destino. Seguindo esse 
modelo passo-a-passo, o algoritmo de roteamento de cada roteador intermediário roteia o 
datagrama para o próximo roteador, até que algum deles possa realizar uma entrega direta 

a estação destino. Assim, os datagramas atravessam a inter-rede e são encaminhados de um 


roteador para outro, até que possam ser entregues diretamente ao destino final. 


Para implementar o modelo de roteamento passo-a-passo, tipicamente, a tabela de rotea- 
mento contém rotas representadas por pares (N, R), em que N é o endereço da rede destino 
e Ré o endereço IP do próximo roteador (next-hop) do caminho até a rede N. Geralmente, R 
reside em uma rede diretamente conectada, permitindo a entrega direta do datagrama para 
ele. Quando a rede N já é diretamente conectada, ao invés de indicar um próximo roteador, 
a rota apenas indica que uma entrega direta pode ser realizada ao destino. 


A Figura 7.2 ilustra uma inter-rede de exemplo, mostrando as tabelas de roteamento dos 
roteadores e algumas estações. Observe que cada entrada da tabela de roteamento indica 
apenas o próximo roteador para cada possível rede destino. Portanto, as rotas não indicam 
o caminho completo até o destino, mas apenas o endereço IP do próximo roteador do 
caminho até a rede destino. Consequentemente, no modelo de roteamento da arquitetura 
TCP/IP, estações origem e roteadores intermediários não conhecem a rota completa até o 


destino, exceto quando o roteador está diretamente conectado. 


Além disso, observe que cada entrada da tabela de roteamento aponta para um roteador 
intermediário que pode ser alcançado através de uma rede diretamente conectada. Ou seja, 
todos os roteadores intermediários listados nas tabelas de roteamento devem estar 


diretamente conectados à mesma rede da estação ou roteador. 


Rede Next-hop Rede Next-hop 


10.0.0.0 Direct 10.0.0.0 200.10.1.2 
150.10.0.0 10.0.0.1 150.10.0.0 200.10.1.2 
200.10.1.0 10.0.0.1 200.10.1.0 Direct 





E OA E on 
N1 = «PRE N2 R2 mm 4 ae 
10.0.0.0 10.0.0.1 x ye 150.10.0.0 150.10.0.2 y tam 








N3 
200.10.1.0 







4 4 


Rede Next-hop Rede Next-hop 
10.0.0.0 Direct 10.0.0.0 150.10.0.1 


150.10.0.0 Direct 150.10.0.0 Direct 
200.10.1.0 150.10.0.2 200.10.1.0 Direct 
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Na Figura 7.2, quando a estação E1 deseja enviar datagramas à estação E2, que está conec- 
tada à mesma rede física, o algoritmo de roteamento da estação E1 identifica que a estação 
E2 pertence à rede 10.0.0.0 e, assim, encaminha o datagrama diretamente para E2. Nesse 
caso, observe que a tabela de roteamento da estação E1 possui a rota (10.0.0.0, Direct), indi- 
cando que a rede 10.0.0.0 está diretamente conectada à estação E1. 


No entanto, quando a estação E1 deseja enviar datagramas à estação E3, que está conec- 
tada a uma rede física distinta, o algoritmo de roteamento da estação E1 identifica que a 
estação E3 pertence à rede 200.10.1.0 e, assim, roteia o datagrama para a interface 10.0.0.1 
do roteador R1. Nesse caso, a tabela de roteamento da estação E1 possui a rota (200.10.1.0, 
10.0.0.1), indicando que a rede 200.10.1.0 pode ser alcançada através da interface 10.0.0.1 do 
roteador R1, que está diretamente conectada à mesma rede da estação E1. Então, baseado 
na rota (200.10.1.0, 150.10.0.2), o algoritmo de roteamento do roteador R1 encaminha o 
datagrama para a interface 150.10.0.2 do roteador R2. Por fim, o algoritmo de roteamento 
do roteador R2 identifica que a rede destino 200.10.1.0 está diretamente conectada e, assim, 
encaminha o datagrama diretamente à estação E3. 


Rotas para estações 


o Permitem realizar testes e depuração de tabelas de roteamento. 
a Adotadas para controle de acesso. 
o Devem ser evitadas para não aumentar o tamanho das tabelas de roteamento. 
o Também representadas por pares (N, R). 
m N: endereço da estação de destino. 
m R: endereço do próximo roteador. 
a O algoritmo de roteamento prioriza rotas para estações. 
Embora o roteamento adote o modelo baseado em endereços de rede, rotas específicas 
para estações também são suportadas pelas implementações do protocolo IP. Rotas para 
estações também são representadas por pares (N, R), porém, nesses casos, o termo N é o 


endereço IP da estação destino, enquanto R é o endereço IP do próximo roteador (nexthop) 


do caminho até a estação destino N. 


O algoritmo de roteamento sempre prefere rotas para estações a rotas para redes. Em 
outras palavras, o algoritmo de roteamento tenta, primeiramente, uma rota específica para 
a estação destino do datagrama. Se uma rota específica não existe, então a rota para a res- 
pectiva rede destino é adotada. 


Rotas para estações proveem melhor controle sobre o uso da rede, permitindo a realização 
de testes e depuração de conexões de rede e tabelas de roteamento. Além disso, rotas para 
estações podem ser adotadas como mecanismo de controle de acesso. Na prática, porém, 
rotas para estações devem ser utilizadas apenas quando estritamente necessárias, evi- 


tando, assim, o aumento desnecessário das tabelas de roteamento. 


Rota padrão (default) 


o Consolidam diversas rotas em uma única entrada da tabela de roteamento. 
o Reduzem o tamanho das tabelas de roteamento. 


o Tornam o roteamento mais eficiente. 






Figura 7.3 
Rotas padrdo. 


a São representadas por um par (N, R). 
m N: endereço reservado 0.0.0.0. 
m R: endereço do próximo roteador. 


a Adotadas apenas quando não existe uma rota para a estação ou rede de destino. 


Rota padrão é a rota adotada quando nenhuma outra rota da tabela de roteamento está 
associada ao endereço de rede do destino do datagrama. Comumente, muitas redes físicas 
possuem apenas uma única conexão com as demais redes que compõem a inter-rede 
institucional, ou mesmo a internet. Por exemplo, na Figura 7.3, as redes N1 e N3 possuem 
apenas uma única conexão com as demais redes através dos roteadores R1 e R2, respectiva- 


mente. Nesses casos, o conceito de rota padrão pode ser utilizado para reduzir o tamanho 


das tabelas de roteamento, tornando mais eficiente o roteamento em roteadores e estações. 


Rede Next-hop Rede Next-hop 
10.0.0.0 Direct 200.10.1.0 Direct 
Default 10.0.0.1 Default 200.10.1.2 


E a A a 
— » S E R1 N2 R2 mm > a k 
ae ~ 150.10.0.0 ) 150.10.0.2 ^ >., ye 


4 


Rede Next-hop 
150.10.0.0 Direct 






N3 
200.10.1.0 







Rede Next-hop 
10.0.0.0 Direct 
150.10.0.0 Direct 
Default 150.10.0.2 


200.10.1.0 Direct 
Default 150.10.0.1 





A rota padrão permite a consolidação de diversas rotas em uma única entrada da tabela de 
roteamento. Por exemplo, considerando a inter-rede da Figura 7.3, as tabelas de roteamento 
das estações E1 e E3, ao adotarem rotas padrão, são reduzidas. Observe que nas estações 
E1 e E3 as duas rotas que apontavam para 10.0.0.1 e 200.10.1.2, respectivamente, foram 


consolidadas em uma única rota padrão. 


Para ilustrar a maior redução das tabelas de roteamento, suponha que diversos roteadores e 
redes físicas foram conectados à rede N2 e aos roteadores R1 e R2 (Figura 7.3). Observe que, 
nesse caso, as tabelas de roteamento das estações E1 e E3 continuam a ser aquelas apresen- 
tadas na figura. Embora o exemplo apresente o uso de rotas padrão apenas em estações, 
roteadores também podem definir rotas padrão. Por exemplo, suponha que diversos rotea- 
dores e redes físicas foram conectados à rede N3 e ao roteador R2. Nesse caso, a tabela de 
roteamento do roteador R1 pode ser configurada, adotando rota padrão, como ilustra a Figura 
Ta: 


Lembre-se de que o endereçamento IP reserva o endereço 0.0.0.0 para representar 
Q) a rota padrão. Por exemplo, a rota (default, 150.10.0.2) é internamente representada 
(0.0.0.0, 150.10.0.2). 


Um datagrama é encaminhado pela rota padrão somente quando nenhuma outra entrada da 
tabela de roteamento está associada ao endereço de rede do destino do datagrama. Assim, o 
algoritmo de roteamento tenta, primeiramente, uma rota específica para a estação de destino. 
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Se esta rota específica para a estação de destino não existe, o algoritmo de roteamento tenta uma 


rota para a rede de destino. Se a rota para a rede não existe, então a rota padrão é adotada. 


Rotas nulas 


o Próximo roteador (next-hop) é “nulo”. 

a Simplesmente descarta os pacotes que utilizam essa rota. 
a Usadas para mitigar ataques de negação de serviço. 

o Podem ser utilizadas para evitar loops de roteamento. 


Usualmente, o próximo passo (next-hop) para se chegar a um determinado destino é outro 
roteador, ou então uma interface física conectada à rede onde se localiza o destino final do 
pacote. No entanto, em alguns casos, é desejável que uma rota aponte para um próximo 
roteador (next-hop) “nulo”, fazendo com que os pacotes que utilizam essa rota sejam 
descartados. Chamamos esse tipo de rota de rota nula ou blackhole (buraco negro). A rota 
nula funciona como uma espécie de regra de firewall, com a vantagem de que o impacto no 
desempenho do roteador é quase inexistente. Por isso, rotas nulas são comumente usadas 
para mitigar ataques de negação de serviço nos roteadores de grandes provedores. Rotas 
nulas são também utilizadas para se evitar um problema conhecido como loop de rotea- 
mento, que veremos a seguir. 


Rede Next-hop 
200.200.200.0/24 192.168.0.2 
200.200.201 .0/24 192.168.0.2 
192.168.0.0/30 Conectada 


200.200.200.0/24 
200.200.201.0/24 
Rota Default 


rG EAE Rede Next-hop 
200.200.200.0/24 Hi > | 200.200.200.0/24 Conectada l 
` 192.168.0.0/30 Conectada Figura 7.4 


Default 192.168.0.1 Loop de 
roteamento. 





Um loop de roteamento acontece quando há uma condição cíclica no roteamento dos 
pacotes. Normalmente é causada por erros na configuração de roteadores. Para entender 
melhor como isso acontece, vamos ver um exemplo. 


Considere uma topologia de rede simples (Figura 7.4), onde o roteador R1, de um provedor 
de acesso, está conectado ao roteador R2 de um cliente. O provedor designou dois blocos 
/24 para o cliente, que deverão ser configurados no roteador R2 (200.200.200.0/24 e 
200.200.201.0/24). No entanto, como ainda não havia necessidade de se utilizar o segundo 
bloco, o administrador de redes do cliente configurou apenas o primeiro bloco no roteador 
R2 (200.200.200.0/24), embora as rotas para ambos os prefixos já tenham sido configuradas 
pelo provedor no roteador R1. Considere a rede onde estão os dois roteadores como sendo a 
rede 192.168.0.0/30. 





f 
o £ 
o 
o 
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Figura 7.5 
Listagem das 
tabelas de 
roteamento. 


Comando route 


Sua função é listar a 
tabela de roteamento. 


A tabela de roteamento do roteador R2 possui rotas para as redes 192.168.0.0/30 e 
200.200.200.0/24, que estão diretamente conectadas, e uma rota padrão. Se uma estação, 
localizada na rede do provedor, enviar um pacote com destino à rede 200.200.201.0/24, ele 
será encaminhado pelo roteador R1 para o roteador R2. Como o roteador R2 não possui 
uma rota específica para essa rede, ele utilizará a sua rota padrão para encaminhar o pacote 
de volta para o roteador R1. Esse ciclo continuará até o TTL do pacote expirar. Uma forma 

de evitar essa situação é inserir uma rota nula para a rede 200.200.201.0/24 no roteador R2, 


enquanto esse bloco não é efetivamente usado. 


Listando tabelas de roteamento 





R2 


~j < ; N2 ~ t ; Na 
x es 150.10.0.1 À  150.10.0.0 } 150.10.0.2 E a 200.10.1.2 1 200.10.1.0 





> route -n 


Destination Gateway Genmask Flags Metric Ifaces 
10.0.0.0 0.0.0.0 2550.00 U 0 etho 
150.10.0.0 0.0.0.0 255) 21595) 0.0 U 0 ethl 
ERRO) 0.0.0.0 2550,00 U 0 lo 
0.0.0.0 LS QRO RO ZORRO UG 0 ethl 


Com base no conhecimento sobre a representação de rotas, podemos apresentar exemplos 
práticos de tabelas de roteamento em sistemas Linux. Observe a Figura 7.5, que mostra a 
tabela de roteamento do roteador R1. O comando route lista a tabela de roteamento e, por 


default, mostra os nomes associados aos endereços de redes e roteadores. A opção -n força 


a apresentação apenas dos endereços. 


Observe que, na prática, a tabela de roteamento possui mais informações que apenas os 
pares (N, R). As principais informações mostradas incluem: 
o Endereço da rede destino (Destination), em que 0.0.0.0 ou default representa a rota padrão. 


ao Endereço do próximo roteador (Gateway), em que 0.0.0.0 ou um asterisco (*) indica um 
destino diretamente conectado. 


a Mascara da rede destino (Genmask), em que 0.0.0.0 e 255.255.255.255 são as máscaras 


de uma rota padrão e de uma rota para a estação, respectivamente. 
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a Estado da rota (Flags). 
o Métrica da rota (Metric). 


o Interface usada para enviar os datagramas (lface). 
Principais indicadores de estado da rota: 


ao U -rota válida (up). 
a H-rota para a estação (host). 


a G-rota indireta via um roteador intermediário (gateway). 


® 
Exercício de fixação iG 
Análise de tabela de rotas 


Na Figura 7.5, é destacada a tabela de rotas do roteador R1. 


Para quais redes o roteador poderá encaminhar pacotes? 


Qual interface do roteador R1 será responsável por encaminhar pacotes para a rede 200.10.1.0? 





Qual entrada na tabela de rotas irá tratar os pacotes originados de 10.0.0.0 para 200.10.1.0? 








Similarmente, a opção -n força a apresentação dos endereços, ao invés de nomes de redes 
e roteadores. A Figura 7.6 mostra a tabela de roteamento do roteador R1. Observe que o 


comando netstat não mostra as métricas das rotas. 


R2 





> netstat -rn 


Destination Gateway Genmask Flags Ifaces 
10.0.0.0 0.0.0.0 255000 U etho 
150.10.0.0 0.0.0.0 Zoor oO) U ethl 
127.0.0.0 0.0.0.0 255.0.0.0 U lo 
0.0.0.0 150), 10.0.2 0.0.0.0 UG ethl 





Comando netstat -r 


Sua função é listar a 
tabela de roteamento. 





N3 


Ra ye 150.10.0.1 À 150.10.0.0 } 150.10.0.2 pona 200.10.1.0 





Figura 7.6 
Tabela de 
roteamento do 
roteador R1. 


Comando ifconfig 


Sua função é confi- 
gurar os endereços das 
interfaces e automati- 
camente instalar rotas 
para as redes direta- 
mente conectadas. 


Estratégias de roteamento 


Sabendo que os algoritmos de roteamento encaminham os datagramas consultando as 
tabelas de roteamento, vamos, a seguir, descrever as diferentes formas de inicialização e 
manutenção das tabelas de roteamento. 


Roteamento estático 


7 
o Permite instalar ou remover manualmente rotas estáticas. E 
a Rotas devem ser manualmente atualizadas após mudanças na inter-rede. 
no Processo é lento e sujeito a erros. 
ao Não acomoda crescimento e mudanças na inter-rede de forma satisfatória. 


a Adequado para inter-redes pequenas, simples e estáveis. 





a Comandos de configuração de rotas são incluídos em arquivos de inicialização. 


Roteamento estático é a estratégia de roteamento na qual as tabelas de roteamento de rote- 
adores e estações são manualmente configuradas pelo administrador. As tabelas de rote- 
amento podem ser diretamente manipuladas pelos administradores através de comandos 
específicos, que permitem instalar ou remover rotas manualmente. Assim, os administra- 
dores podem configurar as tabelas de roteamento de roteadores e estações, definindo as 
rotas para todos os possíveis destinos. As rotas configuradas manualmente são denomi- 
nadas de rotas estáticas. Da mesma forma, a estratégia de roteamento baseada apenas em 


rotas estáticas é denominada de roteamento estático. 


No roteamento estático, sempre que redes são acrescentadas, removidas ou mudam de 
estado operacional, os administradores devem atualizar, manualmente, as tabelas de rote- 
amento de todos ou de parte dos roteadores e estações. Portanto, o roteamento estático 
pode consumir bastante tempo de configuração e está sujeito a erros, não acomodando de 


forma satisfatória o crescimento e as mudanças na inter-rede. 


Consequentemente, o roteamento estático é adequado para inter-redes pequenas, simples e 
estáveis, em que as redes físicas possuem apenas uma única conexão com as demais redes que 
compõem a inter-rede, não existindo rotas redundantes e em um contexto em que mudanças 
no estado operacional das várias redes sejam incomuns. Essas características reduzem o 
tamanho das tabelas de roteamento e evitam a constante configuração manual de rotas. 


Por exemplo, na inter-rede da Figura 7.6, as tabelas de roteamento dos roteadores e esta- 
ções podem ser facilmente configuradas pelos administradores, pois apenas um pequeno 


conjunto de rotas precisa ser efetivamente criado. 


No roteamento estático, na prática, as entradas das tabelas de roteamento são criadas 
por comandos que realizam a configuração do endereçamento das interfaces de rede 
e, também, por comandos específicos que permitem a configuração de rotas estáticas. 


Geralmente, tais comandos são incluídos em arquivos de configuração que são processados 


durante a inicialização dos sistemas. 2 
oO 

E 

Por exemplo, em sistemas Linux, o comando ifconfig configura os endereços das interfaces e 2 
R ETA na PAS SRT pn rc Po oes z 
automaticamente instala rotas para as respectivas redes diretamente conectadas. A Figura 7.7 m 
~N 

mostra a configuração do endereço da interface eth1 do roteador R1 da Figura 7.6 e a definição o 
> 

automática da rota para a respectiva rede. E 
S 

A 
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O comando route, por sua vez, permite criar e remover rotas da tabela de roteamento. 

Na mesma figura, é mostrada a criação de uma rota estática para a rede 200.10.1.0/24 no 
roteador R1. A opção add indica que uma rota deve ser criada para a rede 200.10.1.0 (-net), cuja 
máscara é 255.255.255.0 (netmask), via o roteador intermediário 150.10.0.2 (gw). Para criar rotas 


para estações, deve-se adotar a mesma sintaxe, porém substituindo a opção -net por -host. 
> ifconfig erni 150.10.0.1 netmask 255.255.0.0 

> route =i 

Destination Gateway Genmask Flags Metric Iface 


150.10.0.0 0.0.0.0 2592592050 U 0 ethl 


> route add -net 200.10.1.0 netmask 255.255.255.0 gw 150.10.0.2 


> route -n 


Destination Gateway Genmask Flags Metric Iface 
150), 100.0 0.0.0.0 APR o A) U 0 ethl 
2001010 150 10-02 255, 255,,.255,0) UG 0 ethl 


> route add default gw 10.0.0.1 


> route -n 


Destination Gateway Genmask Flags Metric Iface 

10.0.0.0 0.0.0.0 2550.0). U 0 etho Figura 7.7 
Roteamento 

0.0.0.0 10.0.0.1 0.0.0.0 UG 0 etho estatico. 


Para remover rotas, deve-se utilizar o comando route com a opção del. Similarmente, 
deve-se adotar a mesma sintaxe para remover rotas para estações, porém substituindo a 
opção -net por -host. 


O comando route também permite criar e remover a rota padrão. A Figura 7.7 ilustra a 
criação da rota padrão na estação E1. A opção add default indica que uma rota padrão deve 
ser criada via o roteador intermediário 10.0.0.1 (gw). Para remover a rota padrão, basta 
substituir a opção add por del. 


Roteamento dinâmico 

a Adota protocolos de roteamento para criar, remover e atualizar rotas dinâmicas. 

a Rotas são manipuladas de forma automática, rápida e confiável. 

a Melhora a confiabilidade da rede e o tempo de resposta às mudanças operacionais. 
a Adequado para inter-redes grandes, complexas e instáveis. 

a Adequado também para redes pequenas com rotas redundantes e mudanças frequentes. 


Estratégia de roteamento em que todas as tabelas de roteamento de roteadores e esta- 
ções são automaticamente configuradas pelos protocolos de roteamento. Em inter-redes 


complexas, grandes e instaveis, tal como a internet, os administradores ndo conseguem 
atualizar as rotas manualmente, de forma rápida e confiável, em resposta as mudanças na 
inter-rede. Portanto, protocolos de roteamento devem ser adotados para atualizar automa- 
ticamente as tabelas de roteamento, de modo a melhorar a confiabilidade da rede e o tempo 


de resposta às mudanças operacionais. 


Vale ressaltar que protocolos de roteamento também podem ser interessantes em redes 
pequenas que possuem rotas redundantes e que apresentam frequentes mudanças na situ- 
ação operacional das redes físicas. Nesses casos, a atualização das rotas pode ser realizada 


de forma automática, rápida e confiável. 


Para realizar a atualização automática das rotas, os protocolos de roteamento propagam 
informações de roteamento, a partir das tabelas de roteamento completas e consistentes que 
podem ser dinamicamente configuradas. Na prática, os protocolos de roteamento permitem a 


criação de novas rotas, atualização de rotas existentes e remoção de rotas inválidas. 


Por exemplo, quando o protocolo de roteamento detecta uma nova rede física, uma nova 
rota é acrescentada às tabelas de roteamento. Após perceber alterações nas métricas de 
roteamento, o protocolo de roteamento pode atualizar as métricas das rotas. Por fim, se 
o protocolo de roteamento detecta a falha de um determinado enlace, as rotas afetadas 
podem ser removidas e rotas alternativas, que resolvem o problema, podem ser criadas. 


Quando existem rotas redundantes, o protocolo de roteamento encontra múltiplas rotas para 
determinados destinos. Nesses casos, com base nas métricas de roteamento, o protocolo de 
roteamento escolhe a melhor rota e a instala na tabela de roteamento. Alguns protocolos instalam 
múltiplas rotas na tabela de roteamento e, dependendo da implementação, o algoritmo de rotea- 
mento usa apenas a melhor rota ou realiza o balanceamento de carga entre essas possíveis rotas. 


As rotas manipuladas pelos protocolos de roteamento são denominadas rotas dinâmicas 
e, por consequência, a estratégia de roteamento baseada apenas em rotas dinâmicas é 
chamada de roteamento dinâmico. A adoção do roteamento dinâmico não muda a forma 
como o algoritmo de roteamento encaminha os datagramas. As entradas das tabelas de 


roteamento é que são modificadas para refletir as mudanças na inter-rede. 


Roteamento híbrido 


Inicialmente, as tabelas de roteamento são configuradas com rotas estáticas. 
a Rotas diretas para redes diretamente conectadas. 
a Rotas estáticas para redes que proveem serviços essenciais. 


Posteriormente, protocolos de roteamento complementam as tabelas de roteamento, 


através de rotas dinâmicas para as demais redes físicas que compõem a inter-rede. 


Estratégia de roteamento em que as tabelas de roteamento de roteadores e estações são 
inicialmente configuradas com algumas rotas estáticas e, posteriormente, complementadas 
com rotas dinâmicas. As estratégias de roteamento estático e dinâmico têm suas vantagens 
e desvantagens. O roteamento dinâmico pode resolver situações complexas de roteamento 
de forma mais rápida e confiável. Porém, consome recursos de processamento e comuni- 


cação para propagar e processar as informações de roteamento. 


O roteamento estático evita o consumo de recursos de processamento e comunicação, pois 
não existe propagação de informações de roteamento. Entretanto, não acomoda de forma 
satisfatória o crescimento e as mudanças operacionais, pois a intervenção manual é lenta e 


sujeita a erros. Consequentemente, na prática, é comum encontrarmos uma estratégia de 
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roteamento híbrida. Nesse caso, a configuração inicial da tabela de roteamento é composta 
por rotas diretas para as redes diretamente conectadas e por rotas estáticas para as redes 


que proveem serviços essenciais de conectividade. 


Em seguida, os protocolos de roteamento acrescentam rotas dinâmicas para as demais 
redes físicas que compõem a inter-rede. No roteamento híbrido, geralmente, as estações 
são configuradas com rotas estáticas. 


Arquiteturas de roteamento 


Conforme já foi mencionado, tanto os esquemas de endereçamento quanto os protocolos 
de roteamento são classificados nas categorias classful ou classless. Da composição de 
esquema de endereçamento e os protocolos de roteamento derivam as arquiteturas de 


roteamento classful e classless. 


A arquitetura de roteamento classful é caracterizada pela adoção do esquema de endereça- 
mento classful e protocolos de roteamento classful. Já a arquitetura de roteamento classless 
é caracterizada pela adoção do esquema de endereçamento classless e protocolos de rote- 
amento classless. Embora a diferença entre os protocolos de roteamento classful e classless 
pareça pequena (apenas a incapacidade ou a capacidade de propagar as máscaras de rede), 
os efeitos são importantes. 


Arquitetura classful 


ao Adota o esquema de endereçamento e protocolos de roteamento classful. 
a Protocolos de roteamento não propagam as máscaras das sub-redes. 
ao Algoritmo de roteamento deve deduzir as máscaras das sub-redes. 


m Assume que as sub-redes, derivadas de um endereço classe A, B, ou C, adotam 


máscaras idênticas. 
m Suporta apenas sub-redes com máscaras de tamanho fixo. 
ao Algoritmo de roteamento: 
m Extrair endereço IP de destino (D) do datagrama. 
m Determinar o endereço da rede ou sub-rede de destino (N): 
a Identificar o endereço da rede (C) classe A, B ou C. 
m Deduzir a máscara da rede ou sub-rede de destino (S): 
a Se existe alguma interface de sub-redes do endereço de rede C: 
a Deduzir a máscara S a partir da configuração dessa interface. 
a Senão:Assumir que a máscara S é igual à máscara default da rede C. 
a Deduzir o endereço da rede ou sub-rede destino (N = D and S). 
m Se existe rota para o destino D: 
a Rotear o datagrama para o roteador R dessa rota e sair. 
m Se existe rota para a rede N: 
a Rotear o datagrama diretamente ou via o roteador R dessa rota e sair. 
m Se existe rota padrão: 
a Rotear o datagrama para o roteador R indicado na rota padrão e sair. 


m Gerar mensagem de erro. 


Na arquitetura de roteamento classful, os protocolos de roteamento classful não propagam as 
máscaras das sub-redes. Dessa forma, o algoritmo de roteamento não conhece as máscaras das 
sub-redes, cujas rotas foram aprendidas por meio dos protocolos de roteamento. Consequente- 


mente, o algoritmo de roteamento deve adotar algum mecanismo para deduzir estas máscaras. 


Para permitir a dedução das máscaras, a arquitetura classful suporta apenas sub-redes com 
máscaras de tamanho fixo. Em outras palavras, a arquitetura classful assume que todas as 


sub-redes derivadas de um determinado endereço classe A, B ou C adotam máscaras idênticas. 


Em função dessa limitação, o algoritmo de roteamento deduz a máscara de uma sub-rede, 
cuja rota foi aprendida por meio de um protocolo de roteamento, a partir da configuração 
de interfaces diretamente conectadas a sub-redes do mesmo endereço classe A, B ou C. Por 
exemplo, se a rota para 192.168.10.64 é aprendida por meio do protocolo de roteamento e 
existe uma interface diretamente conectada à sub-rede 192.168.10.32/27, então o algoritmo 


de roteamento deduz que a rota aprendida aponta para a sub-rede 192.168.1.64/27. 


Considerando os conceitos que estudamos, o algoritmo de roteamento classful adota o 
seguinte comportamento: prioritariamente, o algoritmo tenta encaminhar o datagrama 
através de uma rota específica para a estação destino. Em segundo lugar, o algoritmo tenta 
adotar uma rota para a rede destino. Por último, a rota padrão é utilizada. Se nenhuma 


dessas rotas existe, o algoritmo gera uma mensagem de erro. 


Observe também que o algoritmo assume que todas as sub-redes derivadas de um deter- 
minado endereço de rede possuem máscaras idênticas. Essa pressuposição pode ser 
percebida na dedução da máscara da rede destino (S) a partir da configuração de alguma 


interface pertencente a sub-redes do endereço de rede (C). 


Arquitetura classless 


a Adota o esquema de endereçamento e protocolos de roteamento classless. 
a Protocolos de roteamento propagam as máscaras das sub-redes. 
ao Algoritmo de roteamento sempre conhece as máscaras das sub-redes. 


a Permite que as sub-redes, derivadas de um endereço de bloco, adotem máscaras 


diferentes. 
a Suporta sub-redes com máscaras de tamanho variável. 
ao Algoritmo de roteamento: 
m Extrair endereço IP de destino (D) do datagrama. 
m Para cada rota | da tabela, declarar a rota possível se N, = (D and S). 
m Se existe alguma rota possível: 
a Selecionar a rota possível de maior prefixo de rede. 


a Rotear o datagrama para o roteador R da rota selecionada e sair. 





m Gerar mensagem de erro. 


Na arquitetura de roteamento classless, os protocolos de roteamento classless propagam as 
máscaras das sub-redes. Assim, o algoritmo de roteamento sempre conhece as máscaras 
das sub-redes cujas rotas foram aprendidas através dos protocolos de roteamento. Con- 
sequentemente, o algoritmo de roteamento não precisa adotar qualquer mecanismo para 


deduzir estas máscaras. 
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Como as máscaras das várias sub-redes são sempre individualmente propagadas e conhe- 
cidas, a arquitetura classless suporta sub-redes com máscaras de tamanho variável. Em 
outras palavras, a arquitetura classless permite que as sub-redes derivadas de um determi- 
nado endereço de bloco adotem máscaras diferentes. 


O algoritmo de roteamento classless não explora o conceito de classes de endereços e tam- 
pouco adota qualquer pressuposição sobre as máscaras dos blocos. Ao invés disso, o algo- 
ritmo de roteamento classless explora o conceito de equivalência de maior prefixo (longest 
prefix match), realizando uma comparação entre o endereço de destino (D) do datagrama e o 
endereço de destino de cada rota (N) da tabela de roteamento. Essa comparação é realizada 


através da operação lógica entre o endereço de destino D e a máscara da rota S, 


Se o resultado é igual ao endereço de destino da rota (N), então tal entrada é declarada 
uma rota possível. Dentre as rotas possíveis, aquela que possui o maior prefixo de rede é 
escolhida para rotear o datagrama. Observe que a rota possível com o maior prefixo de rede 
é sempre a que possui a maior máscara e, portanto, é a rota mais específica. 


Lembre-se de que rotas para estações e a rota padrão sempre adotam as máscaras 
255.255.255.255 e 0.0.0.0, respectivamente. Portanto, implicitamente, a seleção da rota de 
maior prefixo prioriza as rotas para estações, pois as mesmas possuem a maior máscara 
(255.255.255.255). 


Em seguida, rotas para sub-redes mais especificas sdo priorizadas. Por ultimo, a rota padrdo 
é adotada apenas quando é a única rota possível, pois ela possui a menor máscara (0.0.0.0). 
Vale ressaltar que a rota padrão é sempre uma rota válida. Se nenhuma dessas rotas existe, 
então o algoritmo gera uma mensagem de erro. 


> route -n 


Destination Gateway Genmask Flags Metric Iface 

200.1011 L50101 255) 2552950 UGH 0 etho 

200. 10) 1 150), 10), 44 il 255) 255.255.2955 UGH 0 etho Figura 7.8 
Exemplo de tabela 

0.0.0.0 IL50 30.358 ORORORO UG 0 eth2 de rotas. 


Por exemplo, considerando a tabela de roteamento mostrada na Figura 7.8, um datagrama 
destinado ao endereço 200.10.1.1 possui as entradas 200.10.1.1/32, 200.10.1.0/27 e 0.0.0.0/0 
como rotas possíveis. Nesse caso, o algoritmo adota a rota para a estação 200.10.1.1/32, pois 
ela possui o maior prefixo. 


Por outro lado, um datagrama para o endereço 200.10.1.2 possui as entradas 200.10.1.0/27 
e 0.0.0.0/0 como rotas possíveis. Nesse outro caso, o algoritmo adota a rota para a sub-rede 
200.10.1.0/27, pois ela possui o maior prefixo. Por fim, um datagrama para 192.168.1.1 adota 
rota padrão, que é a única rota possível. 


Protocolos de roteamento padrão 


a ARPAnet 
m Rede pequena. 
a Rotas estáticas. 
a Crescimento da internet 


m Atualização dinâmica das tabelas de roteamento. 


o Protocolos interiores 
a RIP. 
a OSPF. 

o Protocolos exteriores 


m BGP. 


Na arquitetura TCP/IP, diversos protocolos de roteamento foram desenvolvidos para atender 
a necessidades específicas, mas a grande motivação para o seu desenvolvimento foi, sem 


dúvida, o crescimento massivo e sem controle da internet. 


No início da ARPAnet, a rede experimental da agência ARPA do Departamento de Defesa 
norte-americano (DoD), as rotas eram configuradas manualmente pelos administradores 
(rotas estáticas) e funcionavam adequadamente, pois era uma rede pequena. Com o término 
da experiência ARPAnet e o início da internet sustentada pela iniciativa privada, o cresci- 
mento da rede obrigou os administradores a rever essa posição. Surgiram então os proto- 
colos de roteamento que permitiam uma atualização dinâmica das tabelas de roteamento. 


Protocolo RIP 
a Baseado no algoritmo Bellman-Ford. 
ao Métrica hop count. 

o Envia a tabela de rotas completa a cada 30 segundos. 
ao RIPv2 


m Envia informação de máscara de rede (classless). 


a Autentica mensagens. 





a Mensagens multicast. 


Routing Information Protocol (RIP) é o protocolo de roteamento mais antigo baseado no 
algoritmo de vetor distância (Bellman-Ford). Possui duas versões: 
o RIPv1 (classful); 
o RIPv2 (classless). 
O RIPv1 já era distribuído no Unix BSD desde 1982, mas só foi padronizado em junho de 1988 
pelo RFC 1058. Características do RIPv1: 
a Usa a porta 520 do protocolo UDP para enviar mensagens de broadcast; 
o Envia mensagens do tipo request solicitando informações de rotas dos vizinhos; 
o Recebe mensagens do tipo response com atualizações de rotas; 
a Métrica usada é o hop count (contagem de saltos): 
= hop count = 1 (rede diretamente conectada). 
a hop count = 16 (rede inatingível). 
ao Acada 30 segundos envia a tabela de rotas completa através das mensagens do tipo response; 
a Não envia informação de máscara de rede (classful). 


O RIPv2 foi inicialmente definido pelo RFC 1388, de janeiro de 1993, tornado obsoleto pelo 
RFC 1723, de novembro de 1994, e finalmente padronizado pelo RFC 2453, de novembro de 
1998, que tornou obsoletos os anteriores. Principais diferenças em relação ao RIPv1: 
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o Envia informação de máscara de rede (classless); 
a Usa autenticação de mensagens para maior segurança; 


o Usa mensagens multicast para o endereço 224.0.0.9. 
As demais características são semelhantes às do RIPv1. 


A limitação mais séria do protocolo RIP é o fato de não suportar mais de 15 hops, limitando 
seu uso a redes pequenas. Face a isso, foi necessário definir um novo protocolo que supor- 
tasse redes grandes e atendesse às exigências de crescimento da internet. 


Protocolo OSPF 


E 
O protocolo OSPF é baseado na tecnologia de estado de enlace (link state), tendo como 
principais características: 


a Não existe limite de saltos. 

a Suporta VLSM. 

a Convergência mais rápida do que o RIP. 
a Hierarquia de redes. 

ao Divisão da rede em áreas. 


a Mais complexo. 


O protocolo Open Shortest Path First (OSPF), definido no RFC 2328, é um protocolo Interior 
Gateway Protocol (IGP), ou seja, projetado para uso intra-AS (Sistema Autônomo). Foi desen- 
volvido para atender às necessidades da comunidade da internet, que demandava um proto- 


colo IGP eficiente, não proprietário e interoperável com outros protocolos de roteamento. 


A natureza aberta do OSPF significa que ele pode ser implementado por qualquer fabricante, 
sem pagamento de licença, de modo a ser utilizado por todos. O OSPF baseia-se na tecno- 
logia link state, diferente e mais avançada que a usada em protocolos puramente vetoriais, 
como o RIP, que utiliza o algoritmo Bellman-Ford para o cálculo da melhor rota. 


O OSPF resolve todas as limitações do protocolo RIP: 


o Não existe limite de saltos. 
o Suporta VLSM. 


a Utiliza anúncios multicast e as atualizações apenas são disparadas quando existe alguma 
alteração na rede (anúncios incrementais). 


ao Redes OSPF convergem mais eficientemente do que redes RIP, principalmente as 


redes maiores. 


a Permite a implementação de hierarquia às redes, por meio das áreas. Isso facilita o plane- 


jamento da rede, assim como tarefas de agregação e sumarização de rotas. 


O protocolo OSPF permite um meio mais eficaz de balanceamento de carga e a divisão de 
uma rede em áreas. Ele possibilita o roteamento dentro de cada área e através das áreas, 
usando os chamados roteadores de borda. Com isso, é possível criar redes hierárquicas de 
grande porte, sem que seja necessário que cada roteador tenha uma tabela de roteamento 
gigantesca, com rotas para todas as redes, como seria necessário no caso do RIP. Em outras 
palavras, o OSPF foi projetado para intercambiar informações de roteamento em uma inter- 


conexão de redes de tamanho grande ou muito grande. 


A divisão em áreas reduz o tráfego de overhead enviado pela rede, além de reduzir o 
tamanho da base de dados topológica que cada roteador deve manter. Entretanto, o OSPF é 
mais complexo de ser planejado, configurado e administrado, se comparado com RIP. Além 
disso, processos OSPF consomem mais CPU que processos RIP, uma vez que o algoritmo e a 
estrutura utilizados pelo OSPF são muito mais complexos. 


O protocolo OSPF possui algumas restrições quando mais de uma área é configurada. Se 
apenas uma área existe, esta área é SEMPRE a área 0, chamada de backbone area. Quando 
existem múltiplas áreas, uma delas deve ser a área 0. Ao se projetar redes com o protocolo 
OSPF, uma boa prática é começar pela área 0 e expandir a rede com a criação de outras 


áreas (ou segmentando a área 0). 


Protocolo BGP 


o Interliga os Sistemas Autônomos (ASs). 

o IANA atribui a cada AS um numero: ASN. 

a Suporta CIDR. 

ao Permite implementar políticas de roteamento. 


ao Atualização incremental da tabela de rotas. 





o Estabelece sessões BGP com seus vizinhos. 


Parafraseando Douglas Comer, o protocolo de roteamento BGP versão 4 (BGP-4) pode ser 
considerado “a cola que mantém a internet unida e permite a interconexão universal nos 
dias de hoje”. O BGP-4 possibilita o intercâmbio de informações de roteamento entre os 
diversos sistemas autônomos ou Autonomous Systems (ASs), que em conjunto, formam a 
internet. Explicando de forma simplificada, ele permite que os dados trafeguem entre os ASs 


até chegarem ao AS de destino, e dentro dele sigam até o seu destino final (máquina). 


Há alguns anos, quando o principal backbone da internet era a ARPAnet, as instituições de 
pesquisa conectadas à rede precisavam gerenciar manualmente as tabelas de rotas para todos 
os possíveis destinos, ou seja, todas as outras redes conectadas. Com o crescimento da internet, 
verificou-se que era impraticável manter todas as tabelas atualizadas de forma manual, assim 
como também seria necessário criar mecanismos de atualização automática entre as diversas 
redes. Para anunciar as rotas para suas redes internas entre si, os ASs precisavam concordar em 
usar um esquema único, como um mesmo idioma para toda a internet. Para permitir a um algo- 
ritmo de roteamento automatizado distinguir entre um AS e outro, um número (Autonomous 
System Number - ASN) foi designado para cada AS pela IANA, autoridade central encarregada 
de atribuir todos os endereços identificadores das redes conectadas à internet. 


O BGP é um protocolo de roteamento para ser usado entre múltiplos sistemas autônomos 
em inter-redes baseadas no protocolo TCP/IP. O BGP-4 [RFCs 1771, 1772] foi projetado para 
evitar loops de roteamento entre ASs e permitir o uso de políticas de roteamento entre ASs 
com base em regras arbitrárias definidas por eles. Além disso, o BGP-4 foi a primeira versão 
do BGP a suportar endereços agregados (Classless Interdomain Routing, ou simplesmente 
CIDR) e o conceito de super-redes. O protocolo BGP-4 assume que o roteamento interno do 
AS é feito através de um sistema IGP de roteamento interno. Este pode ser um protocolo de 
roteamento como RIP e OSPF, por exemplo, ou até mesmo através de rotas estáticas. 
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O BGP constrói um grafo dos ASs, usando as informações trocadas pelos “vizinhos BGP” (BGP 
neighbors), que são compostas dos números identificadores dos ASs (ASN). A conexão entre os 
ASs forma um “caminho” (path), e a coleção desses caminhos acaba formando uma rota composta 


pelos números dos ASs que devem ser percorridos até se chegar a um determinado AS destino. 


Outra característica do BGP-4 é a atualização das tabelas de rotas feitas de forma incre- 
mental, como nos algoritmos de estado de enlace. A atualização completa da tabela de rotas 


é feita somente uma vez, quando se estabelece a sessão entre os vizinhos. 


E2 Roteiro de Atividades 7 


Figura 7.9 
Rede da Atividade 7.1. 


Atividade 7.1 - Estratégia de roteamento 


Uma determinada instituição possui a inter-rede mostrada na figura 7.9. Suponha que você 
foi contratado como consultor para definir a estratégia de roteamento a ser adotada nesta 
inter-rede. Você recomendaria o roteamento estático ou dinâmico? Apresente argumentos 


favoráveis à sua recomendação e contrários à outra estratégia. 


Em É» 


2 je R3 


++ 
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Atividade 7.2 - Estratégia de roteamento (2) 


Algum tempo depois, a inter-rede da Atividade 7.1 ficou um pouco mais complexa, conforme 
mostra a figura a seguir. Agora, você foi contratado para avaliar a estratégia de roteamento 
atual, sugerida por você anteriormente, e, caso necessário, propor uma nova estratégia. 
Qual a sua avaliação da estratégia atual? É necessária alguma mudança na estratégia de 
roteamento? Explique. 
























































Atividade 7.3 — Rotas estáticas 


Vamos usar a rede da Atividade 7.1 para configurar rotas estáticas. Siga o procedimento: 


1. Inicie o Virtual Box e selecione a opção “Open a Virtual Machine”, selecione a máquina 
virtual “vcore-4.2" no diretório que o instrutor indicar e inicie esta maquina virtual. 


2. Aguarde a carga completa da máquina virtual CORE. 


3. Selecione “File” no menu, selecione a opção “Open” e localize o diretório onde se encontra a 


rede: "Rede Atividade? 3.imn”, seguindo a orientação do instrutor. Carregue o arquivo da rede. 


4. Arede deverá ser idêntica à Figura 7.11 mostrada a seguir. 


Rede da Atividade 7.2. 


Figura 7.11 
Rede da Atividade 7.3. 








Ur 


representadas pelos switches N1, N2, N3 e N4. Cada rede física tem um prefixo de rede 


CORE (48821 on ubuntu) Rede Atividade? 3.imn 


192.168.4.10/24 


diferente, conforme a tabela abaixo. 


Rede 
N1 
N2 
N3 


N4 


Endereço de rede 


192.168.1.0/24 


192.168.2.0/24 


192.168.3.0/24 


192.168.4.0/24 


Gateway padrão 


192.168.1.1 


192.168.2.1 


192.168.3.1 


192.168.4.1 


File Edit Canvas View Tools Widgets Experiment Help 


Nome PC 


PC1 


PC2 


PC3 


PC4 








. Os endereços IPv4 já estão configurados, conforme a figura. Temos 4 redes físicas 


Endereço PC 

192.168.1.10/24 
192.168.2.10/24 
192.168.3.10/24 


192.168.4.10/24 


6. Nenhum tipo de rota ou protocolo de roteamento está configurado. Nesta atividade 


vamos configurar as rotas estáticas nos 3 roteadores: R1, R2 e R3. 


O modo inicial de operação do simulador é o Modo de Edição. Este modo é utilizado para 
desenhar a rede e configurar o endereçamento IPv4. Para efetivamente executar os proto- 
colos de roteamento e as aplicações, é necessário iniciar o experimento, que pode ser feito 


de duas maneiras: 


a Clicando no ícone O a esquerda na barra de ferramentas; 


a Selecionando no menu superior a opção Experiment/Start. 
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No Modo de Experimento, não é possível fazer edição da topologia da rede (note a barra de 
ferramentas modificada). Aguarde até que toda a rede seja iniciada (até desaparecerem os 
colchetes vermelho/verde em cada nó da rede). 


N 


Para configurar rotas estáticas no roteador R1, é preciso abrir o console do roteador. 


Neste simulador o procedimento é o seguinte: 


Aponte com o mouse para o roteador R1, clique no botão direito e selecione a opção: 


Shell window/vtysh, conforme mostrado na Figura 7.12. 












Configure 
Assign to 


rca É Merge 





Hide 

Shell window F vtysh 

Tcpdump 7 {bin/sh Figura 7.12 

View log... bash Abertura do console 


roteador R1. 


8. O console deverá ser parecido com a Figura 7.13, onde digitamos o comando sh ip route, 


que lista as rotas IP conhecidas pelo roteador. 


Hello, this is Quagga (version 0.99.17mr2.0). 


Copyright 1996-2005 Kunihiro Ishiguro, et al. 


R1l# sh ip route 


Codes K = kernel roure, € = connected, S = Static, R = RIP, © = 
OSPF, 


I = ISIS, E = BOP, > = selected route, ~ = Fib Puto, O = 
OSPFv3 


C>* 127.0.0.0/8 is directly connected, lo 
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C>* 192.168.4.0/24 is directly connected, ethl 
Figura 7.13 


Console do R1# 
roteador R1. 


Observe que o roteador R1 só conhece as redes diretamente conectadas: 192.168.1.0/24 e 
192.168.4.0/24. 


9. Vamos precisar “ensinar” ao roteador R1 como encaminhar pacotes para as redes 
192.168.2.0/24 e 192.168.3.0/24, que são redes remotas e que só podem ser alcançadas 
através de outros roteadores. Para isso, os seguintes comandos devem ser digitados no 


console de R1: 


R1$ conf t 


o) 


(config)# ip route 192.168.2.0 255.255.255.0 192.168.4.2 


o) 


(config)# ip route 192.168.3.0 255.255.255.0 192.168.4.3 


o) 


(config)# exit 








Rl# sh ip route 

Codes: k-kernel route, CHcomMmected, S-SiLacie, R-RIP, O-OSPF 
IFILSIS, B-P, >selecrel! route, “=F route, G-OSPFYS 

C>* 127.0.0.0/8 is directly connected, lo 

C>* 192.168.1.0/24 is directly connected, etno 

See M92 IG, 20/24 LOI) vis 192 166,42, Erhi 


See IZ MOS 30/24 ILO wie MZ SA Sell 








C>* 192.168.4.0/24 is directly connected, ethl 
R1# 


Os dois comandos ip route informam as rotas para as redes remotas, dizendo para onde 
encaminhar os pacotes (next-hop). Em seguida listamos a tabela de rotas IP novamente, e 


então aparecem as rotas estáticas para as duas redes remotas. 


Observe que as rotas estáticas aparecem com um “S>*" no início da linha e as redes direta- 


mente conectadas com um “C>*", 


10. Precisamos fazer a configuração de rotas estáticas para os roteadores R2 e R3, adequando 
os comandos mostrados acima às rotas específicas para cada um. Liste a tabela de rotas 
antes e depois de configurar as rotas estáticas para conferir se estão corretas. Dicas: 


a Roteador R2 - rotas para as redes 192.168.1.0/24 e 192.168.3.0/24; 
a Roteador R3 - rotas para as redes 192.168.1.0/24 e 192.168.2.0/24. 


11. Todos os roteadores conhecem as rotas para todas as redes, portanto podemos testar 
a conectividade entre os PCs. Por exemplo, a partir do PC1 vamos enviar ping para os 


demais PCs. Para isso, siga o seguinte procedimento: 


a Aponte com o mouse para o PC1, clique no botão direito e selecione a opção: 
Shell window/bash. 
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No console do PC1, digite o seguinte comando (ping para o PC2): 
root@PC1:/tmp/pycore.39156/PC1.conf# ping -c 2 192.168.2.10 

O resultado deve ser semelhante ao listado a seguir. 

PING 192.168.2.10 (192.168.2.10) 56(84) bytes of data. 

64 bytes from 192.168.2.10: icmp req=1 ttl=62 time=198ms 

64 bytes from 192.168.2.10: icmp_req=2 ttl=62 time=1.95ms 

==- 102. Mo 2/0) ping statistics === 

2 packets transmitted, 2 received, 0% packet loss, time 1005ms 
rtt min/avg/max/mdev = 1.957/100.115/198.273/98.158 ms 
root@PC1:/tmp/pycore.39156/PC1.conf# 


12. Se digitarmos o comando traceroute para o PC3, o resultado deve ser semelhante ao 
listado a seguir. 





root@PCl:/tmp/pycore.39156/PCl.conf# traceroute -n 192.168.3.10 
traceroute to 192.168.3.10 (192.168.3.10), 30 hops max, 60 bytes packet 
1 192.168.1.1 (192.168.1.1) 14.144 ms 0.189 ms 0.104 ms 

2 192.168.4.3 (192.168.4.3) 33.604 ms 33.412 ms 


3 192.106310 (192.168310) 46-033 is 46.228 ms 45.650 ims 





root@PC1:/tmp/pycore.39156/PC1.conf# 


Observe que o pacote seguiu a rota configurada no roteador R1. Os mesmos testes devem 


ser efetuados entre os demais PCs. Todos devem funcionar. 
Atividade 7.4 — Rotas RIP 
Vamos usar a mesma rede da Atividade 7.1 para configurar rotas RIP. Siga o procedimento: 


1. Selecione “File” no menu, selecione a opção “Open” e localize o diretório onde se encontra 


a rede: “Rede_Atividade7_4.imn”, seguindo a orientação do instrutor. 


Q Este arquivo é diferente do arquivo da atividade anterior. O protocolo RIP está habili- 


tado, mas não está configurado. 


2. A rede deverá ser idêntica à da Figura 7.11. 
3. Nesta atividade vamos configurar as rotas RIP nos 3 roteadores: R1, R2 e R3. 


4. Para configurar rotas RIP no roteador R1 é preciso abrir o console do roteador. A configu- 


ração é mais simples do que a anterior. Basta digitar os comandos: 
R1l# conf t 

Ri(config)f router rip 

R1(config-router)# network 192.168.0.0/16 


R1# 


São os mesmos comandos em TODOS os roteadores. Só depois de todos os roteadores 
estarem configurados é que as tabelas de rotas estarão completamente atualizadas. Note 
que informamos no comando network a rede que deve ser anunciada pelo protocolo RIP 
aos demais roteadores (vizinhos). Não precisamos informar as sub-redes, basta informar a 
super-rede: 192.168.0.0/16. Essa super-rede é na verdade um bloco de 256 redes classe C: 
192.168.0.0/24, 192.168.1.0/24,..., 192.168.255.0/24 (ver RFC 1918). O protocolo RIP descobre 


as sub-redes classe C pela máscara de sub-rede. 


5. Para verificar as tabelas de rotas, basta digitar o comando sh ip route listado abaixo, com 


o resultado correspondente, no caso do roteador R1. 


Rl# sh ip route 

Codes: k-kKernel route, CconMmectecd, S=Statie, RRP, 0-0SPF 
ISIS, BBE, >selecrel route, Fil route, G-OSPFYS 

C>* 127.0.0.0/8 is directly connected, lo 

C>* 192.168.1.0/24 is directly connected, ETna 

R>* 192.168.2.0/24 [120/2] via 192.168.4.2, ethl, 00:01:06 


Rew OZ, GS 30/248 [120/2] via 192.16643. eli, 00:01:30 








C>* 192.168.4.0/24 is directly connected, ethl 
R1# 
Observe que as rotas RIP aparecem com o indicador “R>*" no lugar do indicador de rotas está- 


ticas da atividade anterior. Os demais roteadores devem mostrar tabelas de rotas semelhantes. 


Q Todas as redes precisam aparecer em todas as tabelas de rotas. 


6. Todos os roteadores conhecem as rotas para todas as redes. Podemos então testar a 
conectividade entre os PCs. Por exemplo, a partir do PC1 podemos enviar ping e/ou trace- 
route para os demais PCs, seguindo o mesmo procedimento da atividade anterior. 


Atividade 7.5 — Rotas OSPF 


Vamos usar a rede da Atividade 7.1 para configurar rotas OSPF. Siga o procedimento: 


1. Selecione “File” no menu, selecione a opção “Open” e localize o diretório onde se encontra 


a rede: "Rede Atividade? 5.imn”, seguindo a orientação do instrutor. 


Este arquivo é diferente do arquivo da atividade anterior. O protocolo OSPF está 


habilitado, mas não está configurado. 


2. Arede deverá ser idêntica à da Figura 7.11. 
3. Nesta atividade vamos configurar as rotas OSPF nos 3 roteadores: R1, R2 e R3. 


4. Para configurar rotas OSPF no roteador R1, é preciso abrir o console do roteador. A confi- 


guração é tão simples quanto a anterior. Basta digitar os comandos: 


Rl# conf t 
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Ri(config-router)f network 192.168.0.0/16 area 0 
R1# 


São os mesmos comandos em TODOS os roteadores. Só depois de todos os roteadores 
estarem configurados é que as tabelas de rotas estarão completamente atualizadas. 
Note que informamos no comando network a rede que deve ser anunciada pelo protocolo 
OSPF aos demais roteadores (vizinhos). Não precisamos informar as sub-redes, bastando 
informar a super-rede: 192.168.0.0/16. 


5. Para verificar as tabelas de rotas, basta digitar o comando sh ip route listado abaixo, com 
o resultado correspondente, no caso do roteador R1. 


R1l# sh ip route 

Codes: Kekeriel route, C-conmectec, S-Stacie, RRIP, O-OSPF 
LISIS. BBCP, sele are do nie Fib route, O-WSPFVS 

C>* 127.0.0.0/8 is directly connected, lo 

0 92.168.1.0/24 [110/10] is directly connected, etno 00:02:33 


Co IZ NSO" ee i 


n 


directly connected, eth0 
0>* 192.168.2.0/24 [110/20] via 192.168.4.2, ethl, 00:01:45 


0>* 192.168.3.0/24 [110/20] via 192.168.4.3, ethl, 00:01:47 














0 92.168.4.0/24 [110/10] is directly connected, ethl, 00:02:28 














C>* 192.168.4.0/24 is directly connected, ethl 
R1# 


Observe que as rotas OSPF aparecem com o indicador “O>*” no lugar do indicador de rotas 


RIP da atividade anterior. Os demais roteadores devem mostrar tabelas de rotas semelhantes. 


(D Todas as redes precisam aparecer em todas as tabelas de rotas. 


6. Todos os roteadores conhecem as rotas para todas as redes. Podemos então testar a 


conectividade entre os PCs. Por exemplo, a partir do PC1 podemos enviar ping e/ou 


traceroute para os demais PCs, seguindo o mesmo procedimento da Atividade 7.3. 


Camada de transporte 









Descrever os protocolos da camada de transporte da arquitetura TCP/IP e apresentar 
os mecanismos do TCP que permitem a entrega confiável de datagramas, enfatizando 





objetivos 


as diferenças com o protocolo UDP. 







Funcionalidades dos protocolos da camada de transporte da arquitetura TCP/IP, 





serviços de datagrama e circuito virtual e processos de aplicação. 






S0}199U09 


Fundamentos da camada de transporte 


A camada de transporte tem o objetivo de prover a comunicação fim-a-fim entre pro- 


cessos de aplicação. Funcionalidades: 
a Serviço de datagramas. 

a Serviço de circuito virtual. 

o Identificação de processos. 


Camada de rede Como vimos, a camada de rede é responsável por encaminhar e rotear datagramas IP entre 


Também conhecida estações da inter-rede. Nesta camada, os endereços IP identificam apenas as estações. 
como camada de 
inter-rede, é respon- 
sável pela transferência 


de dados entre disposi- 
tivos dainter-rede. Neste capítulo, vamos entender os mecanismos adotados pela camada de transporte para 


Logo, após entregar um datagrama IP à estação destino, o protocolo IP não sabe distinguir 


qual dos processos de aplicação deve receber o conteúdo do datagrama. 


Nela se realiza a função permitir que os diversos processos de aplicação, executando em cada estação, possam 


de roteamento. ; 7 
enviar e receber dados de forma independente. 


Na arquitetura TCP/IP, a camada de transporte provê a comunicação fim-a-fim entre pro- 
cessos de aplicação, definindo dois diferentes serviços de transporte: o serviço de data- 
gramas e o serviço de circuito virtual. Em ambos os serviços, a camada de transporte adota 
mecanismos para distinguir e identificar os múltiplos processos de aplicação que estão 
executando em cada estação. A seguir, estudaremos estas modalidades de serviço e discuti- 


remos o mecanismo de identificação de processos de aplicação. 


® É importante não confundir o serviço de datagramas da camada de transporte com o 


serviço de mesmo nome da camada de rede. 
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Serviço de datagramas 


O serviço de datagramas apresenta as seguintes características: a 
a Serviço não confiável 
m Não garante a entrega dos datagramas, podendo perder e retardar datagramas. 
m Provê apenas a detecção de erros, garantindo a integridade dos dados. 


o Serviço sem conexão 
m Datagramas são individuais e independentes. 


m Sequência dos datagramas não é assegurada. 


O serviço de datagramas é um serviço de transporte bastante simples, sendo caracterizado 
como não confiável e sem conexão, capaz de realizar a entrega fim-a-fim de dados entre os 
processos de aplicação de origem e destino, mas não garante que os dados enviados sejam 
entregues sequencialmente. 


Este serviço pode ser visto como uma simples extensão do serviço de entrega de datagramas 
da camada de rede. No entanto, ao contrário deste último, que realiza a entrega de data- 
gramas IP entre estações origem e destino, o serviço de datagramas da camada de transporte 
é capaz de realizar a entrega fim-a-fim entre os processos de aplicação origem e destino. 


Este serviço é considerado não confiável porque não garante que os datagramas enviados 
pela aplicação origem sejam entregues com sucesso à respectiva aplicação destino. Além 
disso, quando os datagramas são entregues à aplicação destino, o serviço não garante a 
entrega na sequência original. Na verdade, datagramas podem ser perdidos, retardados e até 
mesmo chegar fora de ordem. Na prática, o serviço de datagramas provê apenas a detecção 
de erros, não suportando mecanismos de correção de erros, controle de fluxo e controle de 
sequência. Quando desejada, a confiabilidade deve ser provida pela camada de aplicação. 


O serviço de datagramas é denominado sem conexão porque, antes do envio dos data- 
gramas, não existe qualquer comunicação prévia entre as aplicações origem e destino, com 
o objetivo de definir o caminho a ser seguido pelos datagramas ou reservar recursos ao 
longo deste caminho. Consequentemente, cada datagrama é tratado de forma individual 

e completamente independente dos demais, sendo encaminhado ao destino através do 
caminho mais conveniente, definido pela função de roteamento implementada pela camada 
de rede. Logo, nenhuma informação é mantida sobre a sequência dos datagramas enviados. 
Se uma determinada aplicação envia uma sequência de datagramas para outra, estes data- 
gramas podem ser encaminhados pela camada de rede por diversos caminhos, trafegando 
por diferentes redes e roteadores intermediários. Alguns destes datagramas podem ser 
perdidos, enquanto outros podem, inclusive, ser entregues à aplicação destino fora da 
sequência original. 


Serviço de circuito virtual 





a Serviço orientado a fluxo 
a Divide o fluxo de dados em segmentos. 
a Serviço confiável 
a Garante a entrega do fluxo de dados na sequência correta e sem erros. 


a Prové controle de erro, sequência e fluxo. 


Segmento 


Nome da unidade 
de dados do serviço 
de circuito virtual da 

camada de transporte. 


Full-duplex 


Modo de comunicação 
no qual as entidades 
origem e destino podem 
simultaneamente enviar 
dados em ambas 

as direções. 





a Serviço orientado à conexão 
m Negocia parâmetros operacionais na abertura da conexão. 


m Conexões são full-duplex. 


O serviço de circuito virtual é um serviço de transporte confiável e orientado à conexão, 
capaz de realizar a entrega fim-a-fim de dados entre os processos de aplicação origem e 


destino, garantindo que os dados enviados sejam entregues na sequência. 


O serviço de circuito virtual é bem mais complexo que o serviço de datagramas. Este serviço 


divide o fluxo de dados (data stream), gerado pelo processo de aplicação origem em segmentos. 


Por sua vez, estes segmentos são enviados ao processo de aplicação destino. 


Este serviço é considerado confiável porque garante que os dados enviados pela aplicação 
origem são entregues na sequência correta e sem erros à respectiva aplicação destino. 
Portanto, o serviço de circuito virtual provê um fluxo confiável de dados, oferecendo meca- 
nismos implícitos de detecção e correção de erro, controle de fluxo e controle de sequência, 


que garantem um alto nível de confiabilidade. 


O serviço de circuito virtual é denominado orientado à conexão porque, antes do envio do 
fluxo de dados, o processo de aplicação origem deve comunicar-se com o processo de apli- 
cação destino, com o objetivo de abrir uma conexão. Durante a abertura de uma conexão, 
as entidades de transporte envolvidas negociam parâmetros operacionais, como a iniciali- 
zação dos mecanismos de controle de erro, fluxo e sequência, bem como os tamanhos dos 
buffers de transmissão e recepção. A conexão deve permanecer ativa durante a fase de 
transferência de dados. Quando os processos não desejam mais transferir dados, a conexão 
deve ser fechada, liberando os recursos associados nas entidades de transporte envolvidas. 


No serviço de circuito virtual, toda conexão é full-duplex, permitindo a ambos os processos 


enviar e receber dados simultaneamente. 


No contexto de uma conexão, cada segmento não é independente dos demais, pois trans- 
porta informações que permitem ao respectivo destino recuperar a sequência correta 

dos segmentos. Embora o serviço de circuito virtual seja orientado à conexão, quando um 
processo de aplicação envia uma sequência de segmentos para outro, os datagramas IP que 
encapsulam estes segmentos podem ser encaminhados pela camada de rede por diversos 
caminhos, trafegando por diferentes redes e roteadores intermediários. Consequente- 
mente, tais datagramas IP podem ser perdidos, duplicados ou chegar fora da sequência 
original. No entanto, o serviço de circuito virtual provê mecanismos de controle de erro e 
sequência que requisitam a retransmissão de segmentos perdidos ou recebidos com erro, 


descartam segmentos duplicados e reorganizam os segmentos na sequência correta. 


Identificação de processos 

a Uma porta é identificada por um número inteiro positivo que representa um aa 
ponto de comunicação. 

a Processos são associados a portas. 

a Par (endereço IP, porta) identifica unicamente cada ponto de comunicação. 

A maioria dos sistemas operacionais permite a execução simultânea de vários processos 


de aplicação. Para permitir que múltiplos processos, executando em uma mesma estação, 


possam simultaneamente receber e transmitir dados de forma independente, a camada de 
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operacional de um ponto de comunicação para envio e recepção de dados. É importante 
ressaltar que o conceito de porta é adotado tanto no serviço de datagramas, quanto no 
serviço de circuito virtual. 


Cada porta é identificada por um número inteiro positivo que representa um ponto de 
comunicação para envio e recepção de dados. Os processos de aplicação comunicantes 
devem ser associados a portas. Vale ressaltar que um determinado processo de aplicação 
pode estar associado a uma ou múltiplas portas. Portanto, para a camada de transporte, 
cada processo de aplicação (usuário da camada de transporte) é representado por uma ou 
várias portas diferentes. 


A figura 8.1 ilustra um exemplo de associação de processos a portas. Observe que os pro- 
cessos P1 e P2 estão associados às portas 25 e 53, respectivamente. Logo, todos os dados 
recebidos nas portas 25 e 53 são repassados pela camada de transporte para P1 e P2, res- 
pectivamente. Por outro lado, o processo P3 está associado às portas 161 e 162. Portanto, 
todos os dados recebidos nas portas 161 e 162 são repassados para P3. 


(e) eT 


Para permitir a associação de processos de aplicação a portas, o sistema operacional local 


Aplicação 


Transporte 


de cada estação provê uma interface de programação para que os processos possam 


abrir, acessar e fechar portas. O sistema operacional deve assegurar que, sempre que um 
determinado processo requisitar a abertura de uma dada porta, somente este processo 
estará associado àquela porta. Mais detalhes desta interface de programação serão 
estudados no próximo capítulo. No momento, é suficiente entender que os processos 
dispõem de mecanismos para indicar as portas a que desejam se associar, como também 


enviar e receber dados através destas portas. 


Como os números das portas são atribuídos isoladamente pela entidade de transporte de 
cada estação, estes números não são únicos em toda a inter-rede. Para obter um identifi- 
cador único para cada ponto de comunicação (porta), cada entidade de transporte utiliza o 
par (endereço IP, porta), onde o endereço IP identifica a estação na qual a porta está sendo 
usada. Por exemplo, a porta 9.000, usada na estação 192.168.10.1, é identificada unicamente 
pelo par (192.168.10.1, 9000). 


Quando um processo de aplicação origem deseja se comunicar com um processo de aplicação 
destino, o processo origem deve conhecer o endereço IP da estação onde o processo destino 
está executando e a porta associada ao processo destino naquela estação. As mensagens 
enviadas são encapsuladas em datagramas IP. Cada datagrama IP transporta os endereços IP 
de origem e destino, identificando as estações origem e destino. Por outro lado, cada unidade 
de dados do protocolo de transporte inclui um campo de controle que sinaliza as portas 
origem e destino, identificando os processos origem e destino associados a elas. 


Na estação destino, baseada na porta destino, a implementação do protocolo de transporte 
no sistema operacional realiza a demultiplexação, encaminhando o conteúdo das mensa- 
gens recebidas ao respectivo processo de aplicação. Portanto, a porta destino permite a 
entrega das mensagens à aplicação destino associada a ela. Por outro lado, a porta origem 


Figura 8.1 
Identificação de 
processos na 
camada de 
transporte. 


Interface 
de programação 


Conjunto de procedi- 
mentos, funções ou 
métodos providos por 
um componente ou 
biblioteca de software. 


permite à aplicação destino retornar mensagens à aplicação origem, caso necessário. Observe 
que, neste caso, os processos de aplicação invertem seus papéis de origem e destino. 


Protocolos da camada de transporte 


o UDP (User Datagram Protocol) 
m Provêo serviço de datagramas não confiável e sem conexão. 


= Pode ser visto como uma extensão do protocolo IP que realiza a entrega de data- 


gramas entre processos. 


a TCP (Transmission Control Protocol) 





m Provê o serviço de circuito virtual confiável e orientado à conexão. 


Para prover o serviço de datagramas e o serviço de circuito virtual, a camada de transporte 
da arquitetura TCP/IP define dois diferentes protocolos: UDP e TCP. 


O protocolo UDP provê o serviço de datagramas não confiável e sem conexão. Apenas envia 
pacotes, denominados datagramas UDP, de um processo de aplicação para outro, mas não 
garante que eles sejam entregues com sucesso ao processo de aplicação de destino. Desta 
forma, o protocolo UDP pode ser visto como uma simples extensão do protocolo IP. No 
entanto, ao contrário do protocolo IP, que realiza a entrega de datagramas IP entre estações, o 


protocolo UDP realiza a entrega fim-a-fim de datagramas UDP entre processos de aplicação. 


O protocolo TCP provê o serviço de circuito virtual. Ele é um protocolo orientado à conexão 
que provê um fluxo confiável de dados, oferecendo serviços de controle de erro, fluxo e 
sequência. O protocolo TCP divide o fluxo de dados (data stream) em segmentos, que são 
enviados de um processo de aplicação para outro de forma confiável, garantindo que eles 


sejam entregues ao processo de aplicação destino na sequéncia correta e sem erros. 


Protocolo UDP 


Fundamentos: 

ao Define a unidade de dados do serviço de datagramas, denominada datagrama UDP. 
m Especifica o formato e a função dos campos. 

a Multiplexa mensagens geradas pelos processos no serviço da camada de rede. 
m Encapsula datagramas UDP em datagramas IP. 


a Demultiplexa datagramas UDP para os respectivos processos de destino. 





m Extrai mensagens dos datagramas UDP. 


O protocolo UDP é um protocolo de transporte simples que provê o serviço de datagramas 
não confiável e sem conexão. Ele define três importantes conceitos: 


ao Especificação, de forma precisa, do formato da unidade de dados do serviço de data- 
gramas da camada de transporte, denominada datagrama UDP. 


a Multiplexação das mensagens geradas pelos vários processos de aplicação origem no 


serviço provido pela camada de rede. 
a Demultiplexação, no destino, dos datagramas UDP recebidos da camada de rede para os 


respectivos processos de aplicação destino. 


O protocolo UDP utiliza o protocolo IP para transportar datagramas UDP entre as aplicações 


origem e destino. Ou seja, cada mensagem gerada por um processo de aplicação origem é 
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encapsulada em um datagrama UDP, que, por sua vez, é encapsulado em um datagrama IP. 
Então, o protocolo IP encaminha o datagrama IP da estação origem até a estação destino. 
Na estação destino, baseado no campo Protocol do datagrama IP, o sistema operacional 
decodifica o datagrama UDP. Por fim, a implementação do protocolo UDP entrega a men- 
sagem encapsulada ao respectivo processo de destino. 


O protocolo UDP não garante que os datagramas enviados pelo processo de aplicação 
origem sejam entregues com sucesso ao respectivo processo de aplicação destino. Ele provê 
apenas a detecção de erros, assegurando a integridade dos datagramas que por ventura 
venham a ser entregues ao processo de aplicação destino. Além disso, o protocolo UDP não 
implementa qualquer mecanismo de reconhecimento para informar sobre a entrega de 
datagramas à entidade UDP de destino. Portanto, a aplicação origem não tem conhecimento 
sobre a entrega das mensagens à aplicação destino. 


Vale ressaltar que o UDP não implementa correção de erros, controle de fluxo e controle de 
sequência. Portanto, ele não garante que os datagramas sejam entregues na sequência original. 
Na verdade, datagramas podem ser perdidos, retardados e até mesmo chegar fora de ordem. 


Portanto, quando desejada, a confiabilidade deve ser provida pela camada de aplicação. 


Sendo o UDP um protocolo sem conexão, quando um processo de aplicação deseja enviar 
uma mensagem para outro processo, o protocolo UDP simplesmente encapsula a men- 
sagem em um datagrama UDP e o envia ao outro processo. Desta forma, cada datagrama 
UDP é tratado de forma individual e completamente independente dos demais, podendo 
ser encaminhado por diferentes caminhos, definidos pela função de roteamento da camada 
de rede. Além disso, a entidade UDP de origem não mantém nenhuma informação sobre os 
datagramas UDP enviados. 


Formato do datagrama 


a 
Cada datagrama é tratado de forma individual e independente, e pode ser encaminhado 
por diferentes rotas. J 


0 16 31 
> 






Figura 8.2 
Formato do 
datagrama UDP. 


Cada datagrama UDP é dividido em duas partes: cabeçalho e dados. O cabeçalho contém 
informações de controle específicas do protocolo UDP, como as portas origem e destino. 

A porção dos dados encapsula informações de protocolos da camada de aplicação. A figura 8.2 
ilustra o formato de datagramas UDP, detalhando o formato dos campos do cabeçalho. 
Observe que o campo de dados não é explicitamente detalhado, permitindo o encapsulamento 
de diferentes protocolos de aplicação. 


Campos do datagrama 


Source port 
o Porta associada ao processo de origem. 


a Permite ao processo de destino retornar mensagens ao processo de origem. 


Estrutura de dados que 
armazena diversos itens 
de dados, consumidos 
na mesma sequência 
em que são incluídos. 


o Porta de origem é opcional. 
Destination port 

o Porta associada ao processo de destino. 
a Usada na demultiplexação das mensagens encapsuladas nos datagramas. 
Length 

a Tamanho total do datagrama em bytes. 
o Inclui o cabeçalho e os dados. 
Checksum 

a Assegura a integridade do datagrama. 

a Inclui o cabeçalho e os dados. 

ao Detecção de erros é opcional. 


Data 





ao Dados do datagrama. 


Como já sabemos, datagramas UDP transportam as portas associadas aos processos de 
aplicação origem e destino. Os campos Source port e Destination port são usados com este 
propósito. Observe que cada um destes campos possui 16 bits, indicando que o maior 


número de porta possível é 65.535. 


O campo Source port é opcional. Quando indicado, permite que o processo de aplicação 
destino retorne dados para o processo de aplicação de origem. Quando não indicado, o 
processo destino não tem como retornar dados para o processo origem. Neste último caso, 
o valor do campo Source port deve ser 0. Portanto, podemos concluir que a porta O nunca é 


usada por processos de aplicação. 


Na estação destino, o campo Destination port é usado pela entidade UDP para selecionar o 
processo de aplicação destino que receberá a mensagem encapsulada no datagrama. Por- 
tanto, o protocolo UDP utiliza o número da porta destino para demultiplexar os datagramas 


UDP que recebe do protocolo IP. 


No UDP, uma porta é geralmente implementada como uma fila interna do sistema ope- 


racional, utilizada para armazenar as mensagens recebidas. Ao receber um datagrama, o 
sistema operacional verifica se a porta destino do datagrama é igual a alguma porta atual- 
mente aberta. Caso a porta destino exista, o sistema operacional armazena a mensagem 
encapsulada no final da fila daquela porta. Por outro lado, o processo de aplicação asso- 
ciado àquela porta acessa as mensagens armazenadas no início da fila. Caso a porta destino 
não exista, o sistema operacional simplesmente descarta o datagrama UDP e gera uma 
mensagem /CMP port unreachable para a estação origem. Lembre-se de que o comando tra- 
ceroute explora estas mensagens Port unreachable para descobrir a rota entre duas estações 


ou roteadores, no sistema operacional Linux. 


O campo Length indica o tamanho do datagrama UDP em bytes, incluindo o cabeçalho e os 
dados. Logo, sendo o cabeçalho de tamanho fixo (8 bytes), o tamanho mínimo do datagrama 
UDP é de 8 bytes. Este tamanho mínimo somente ocorre quando o campo de dados do data- 


grama UDP não transporta nenhum conteúdo. 


A integridade dos datagramas UDP é assegurada pelo campo Checksum. Portanto, este campo 


é utilizado para detectar erros no datagrama UDP, incluindo os campos de cabeçalho e dados. 
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A detecção de erros é fim-a-fim, sendo calculada pela entidade UDP origem e verificada pela 
entidade UDP destino. Uma vez que o campo Checksum é calculado sobre todo o datagrama, 
ele permite detectar mudanças nos campos de cabeçalho e dados que possam ter ocorrido 


em qualquer ponto intermediário entre a origem e o destino. 


É importante ressaltar que a detecção de erros é opcional. Quando não utilizada pela 
entidade UDP origem, o campo Checksum deve ser preenchido com valor 0. Embora seja 
opcional, é interessante que a detecção de erros seja sempre implementada e habilitada, 
pois o protocolo IP não realiza a detecção de erros do campo de dados, no qual o datagrama 
UDP é transportado. Em outras palavras, a detecção de erros do UDP é a única forma de 
assegurar que os dados recebidos estão corretos. 


Lembre-se de que o protocolo UDP não suporta correção de erros. Quando a enti- 
Q) dade UDP destino detecta um erro no datagrama, este é simplesmente descartado e 


nenhuma mensagem de erro é enviada ao processo de aplicação origem. 


Cálculo do checksum 


a Considera um pseudocabeçalho 

m Assegura que a entrega é realizada à estação e ao processo de destino. 
a Pode incluir um byte pad (0). 

m Torna par o tamanho do datagrama. 
a O pseudocabeçalho e o byte pad não são transmitidos com o datagrama. 
Para calcular o campo Checksum, a entidade UDP origem acrescenta um pseudocabeçalho 
ao datagrama UDP original. O objetivo deste pseudocabeçalho é assegurar, na entidade 
UDP destino, que o datagrama foi realmente entregue à estação destino e ao protocolo de 
transporte destino. Vale ressaltar que o pseudocabeçalho não é transmitido junto com o 


datagrama UDP, sendo utilizado unicamente para calcular o campo Checksum. A figura 8.3 
mostra o formato do pseudocabeçalho. 












0 8 16 31 
Source IP address 
Destination IP address 


Figura 8.3 
UDP. 





Os campos Source IP address e Destination IP address contêm os endereços IP das estações 
origem e destino, respectivamente. O campo Protocol sempre contém o valor 17, indicando 
o UDP como protocolo de transporte destino. O campo Length é apenas uma repetição do 
tamanho do datagrama UDP, incluindo o cabeçalho e os dados. Observe que o pseudocabe- 
çalho não é incluído no campo Length. 


Além disso, para calcular o campo Checksum, o UDP considera que o datagrama possui um 
número par de bytes. Quando o datagrama possui um número ímpar de bytes, o UDP adiciona 
um byte com valor O (pad) ao final do datagrama. Da mesma forma que o pseudocabeçalho, 

o byte pad também não é transmitido junto com o datagrama UDP. 


Segmento TCP 


Unidade de dados do 
protocolo TCP. 


Protocolo TCP 


a Fundamentos 
m Define a unidade de dados do serviço de circuito virtual, denominada segmento TCP. 
m Especifica o formato e a função dos campos. 
a Multiplexa mensagens geradas pelos processos no serviço da camada de rede. 
m Encapsula segmentos em datagramas IP. 
= Demultiplexa segmentos para os respectivos processos de destino. 
m Extrai mensagens dos segmentos. 
ao Adota uma abordagem baseada em fluxo de dados (data stream). 
m Trata o fluxo de dados como uma cadeia contínua de bytes. 
m Decide como agrupar bytes em segmentos. 
ao Adota uma abordagem orientada à conexão full-duplex. 
m Estabelecimento da conexão. 
a Transferência de dados. 
m Fechamento da conexão. 
ao Define mecanismos integrados de controle de erro e sequência. 
m Asseguram a entrega do fluxo de dados na sequência correta e sem erros. 
a Define mecanismo de controle de fluxo. 


= Regula e compatibiliza a taxa de transmissão das entidades envolvidas. 





m Evita o descarte de segmentos por falta de recursos na estação de destino. 


O TCP é um protocolo de transporte bem mais complexo que o UDP. O TCP provê o serviço 
de circuito virtual fim-a-fim, confiável e orientado à conexão. Para tal, o protocolo TCP define 
importantes conceitos e mecanismos. Primeiramente ele especifica, de forma precisa, o 
formato da unidade de dados do serviço de circuito virtual da camada de transporte, deno- 
minada segmento TCP. 


De forma semelhante ao UDP, a implementação do protocolo TCP multiplexa as mensagens 
geradas pelos vários processos de aplicação origem no serviço provido pela camada de 
rede e, no destino, demultiplexa os segmentos TCP recebidos da camada de rede para os 
respectivos processos de aplicação destino. Portanto, ele também utiliza o protocolo IP para 
transportar segmentos entre as aplicações origem e destino. Ou seja, mensagens geradas 
por um processo de aplicação origem são encapsuladas em segmentos, que, por sua vez, 
são encapsulados em datagramas IP. O protocolo IP é então utilizado para encaminhar 
datagramas IP da estação origem até a estação destino. Na estação de destino, baseado no 
campo Protocol dos datagramas IP, o sistema operacional entrega os segmentos à imple- 
mentação do protocolo TCP, que, então, repassa as mensagens encapsuladas ao respectivo 


processo de aplicação destino. 


Enquanto o protocolo UDP é baseado em datagramas independentes, o protocolo TCP é 
orientado a fluxo de dados (data stream). Na prática, podemos pensar o fluxo de dados 
como uma cadeia contínua de bytes, composta pela sequência de mensagens geradas pelo 
processo de aplicação origem. Normalmente, o TCP decide, internamente, a quantidade de 


bytes que devem ser agrupados e encapsulados em um segmento. 
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Portanto, diferentemente do protocolo UDP, onde cada mensagem gerada pelo processo de 
aplicação é encapsulada em um único datagrama UDP, no protocolo TCP, o fluxo de dados 
gerado pelo processo de aplicação origem tem pouco ou nenhum relacionamento com os 
segmentos enviados pela entidade TCP. Ou seja, uma determinada mensagem pode ser divi- 
dida em várias partes e cada uma delas encapsulada em um segmento. Várias mensagens 


também podem ser agrupadas e posteriormente encapsuladas em um único segmento. 


Sendo o TCP um protocolo orientado à conexão, quando um processo de aplicação deseja 


enviar um fluxo de dados para outro processo, a entidade TCP origem deve primeiro requi- 
sitar a abertura de uma conexão com a entidade TCP destino. Na abertura de uma conexão, 
as portas associadas à conexão são definidas e os recursos necessários para gerenciar a 
conexão são reservados nestas entidades. Em seguida, inicia-se a fase de transferência de 
dados na conexão, onde os fluxos de dados gerados pelos processos de aplicação podem 
ser enviados e recebidos. Por fim, quando os processos não desejam mais trocar dados, 
solicitam o fechamento da conexão. Neste momento, as portas e os recursos atribuídos à 
conexão são liberados. Portanto, no TCP, a comunicação entre processos tem três fases: 


abertura da conexão, transferência de dados e fechamento da conexão. 


Vale ressaltar que a conexão TCP é full-duplex, permitindo a ambos os processos enviar e 
receber, simultaneamente, fluxos de dados independentes. Desta forma, observe que os 
termos “processo origem” e “processo destino” são usados apenas para simplificar as expli- 
cações e facilitar o entendimento do uso das conexões. 


Para prover a confiabilidade fim-a-fim, o protocolo TCP define mecanismos integrados de 
controle de erro e sequência. Embora segmentos possam ser perdidos, duplicados, retar- 
dados e até mesmo chegar fora de ordem, os mecanismos de controle de erro e sequência 
asseguram a entrega do fluxo de dados gerado pelo processo origem, na sequência correta 
e sem erros, ao respectivo processo destino. Para tal, o controle de erros realiza a detecção 
e correção de erros, assegurando a integridade dos segmentos recebidos e a recupe- 

ração de segmentos corrompidos. Em complemento, o controle de sequência recupera a 
sequência original do fluxo de dados. Para realizar estas funções, ambos os mecanismos 


exploram mensagens de reconhecimento positivo, que informam a entidade TCP origem 


sobre a entrega com sucesso de segmentos à entidade TCP destino. 


Por fim, o protocolo TCP adota um mecanismo de controle de fluxo que regula e compatibi- 
liza a taxa de transmissão das entidades envolvidas, evitando o descarte de segmentos por 
falta de recursos na estação destino. 





No TCP, cada segmento é dividido em duas partes: cabeçalho e dados. O cabeçalho contém 
informações de controle específicas do protocolo TCP, por exemplo, as portas origem 


Protocolo orientado 
à conexão 


Adota o conceito de 

conexão para gerenciar 
a comunicação entre 

as entidades comuni- 
cantes. Antes de iniciar 
a comunicação, as 
entidades devem esta- 
belecer uma conexão. 
Em seguida, podem 
transferir os dados. Por 
fim, quando não mais 
desejam trocar dados, 
fecham a conexão. 





Reconhecimento 
positivo 


Mensagem de res- 
posta enviada por uma 
entidade que imple- 
menta um determinado 
protocolo para sinalizar 
a correta recepção de 
unidades de dados 
deste protocolo. 


Figura 8.4 
Formato do 
segmento TCP. 


e destino. A porção dos dados encapsula informações de protocolos da camada de aplicação. 
A figura 8.4 ilustra o formato dos segmentos, detalhando os campos que compõem o 
cabeçalho. Observe que o campo de dados não é explicitamente definido, permitindo o 


encapsulamento de diferentes protocolos de aplicação. 
Campos do cabeçalho 


o Hlen 
m Tamanho do cabeçalho em unidades de 4 bytes. 
o Reserved 
m Reservado para uso futuro (não utilizado). 
a Checksum 
m Assegura a integridade do segmento. 
m Considera um pseudocabeçalho. 
= Pode incluir um byte pad (0). 
o Code bits 
m Indica propósito e conteúdo do segmento. 
a URG: dados urgentes. 
a ACK: reconhecimento. 
a PSH: mecanismo push. 
a RST: aborto de conexdo (reset). 
a SYN: abertura de conexdo. 
a FIN: fechamento de conexdo. 
a Options 
a Lista variável de informações opcionais. 
a Maximum Segment Size (MSS) 
m Torna o tamanho do cabeçalho variável. 
oa Padding 
a Bits O que tornam o cabeçalho múltiplo de 32 bits. 


o Data 





m Dados do segmento. 


O tamanho do cabeçalho é variável, mas é sempre múltiplo de 32 bits. Para identificar 
corretamente o cabeçalho, o campo Hen (header length) identifica o tamanho do cabeçalho 
em unidades de 4 bytes. Por exemplo, Hlen igual a 5 representa um cabeçalho de 20 bytes. 
Geralmente, o cabeçalho possui 20 bytes, exceto quando opções estão presentes (Options). 
Observe que o cabeçalho é limitado a 60 bytes, pois Hlen possui 4 bits. O campo Reserved 


não é utilizado, sendo reservado para uso futuro. 


A integridade dos segmentos é assegurada pelo campo Checksum. Portanto, este campo 

é utilizado para realizar a detecção de erros no segmento, incluindo os campos de cabe- 
çalho e dados. A detecção de erros é fim-a-fim, sendo calculada pela entidade TCP origem 

e verificada pela entidade TCP destino. Lembramos que o protocolo TCP suporta correção 
de erros, como veremos adiante. Assim, quando a entidade TCP destino detecta um erro no 
segmento, este é simplesmente descartado e o mecanismo de correção de erros é ativado 


para corrigi-lo via retransmissão. 
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Da mesma forma que o protocolo UDP, para calcular o campo Checksum, o protocolo TCP 
acrescenta um pseudocabeçalho ao segmento original, assegurando que o mesmo será 
realmente entregue à estação destino e ao protocolo de transporte destino. Além disso, 
como no UDP, o TCP pode acrescentar um byte com valor O (pad) ao final do segmento para 
torná-lo múltiplo de 16 bits. 


Vale ressaltar que o pseudocabeçalho e o byte pad não são transmitidos junto com o seg- 
mento, sendo utilizados unicamente para calcular o campo Checksum. O formato do pseudo- 
cabeçalho é idêntico ao usado no UDP. Porém, neste caso, o campo Protocol contém o valor 6, 
indicando o protocolo TCP. 


0 1 2 3 4 5 Figura 8.5 
segmento TCP. 


O campo Code bits é usado para indicar o propósito e conteúdo do segmento. Por exemplo, 
segmentos podem ser usados para estabelecer uma conexão, transferir dados e fechar uma 
conexão. Este campo é composto por 6 bits (Figura 8.5) que sinalizam o modo como outros 
campos do segmento devem ser interpretados. Vários destes bits podem ser ativados em 
um único segmento. 

a URG -segmento transporta dados urgentes; 

a ACK -segmento transporta um reconhecimento; 

a PSH - mecanismo push foi adotado para encaminhar o segmento; 

a RST -sinalização de que a conexão deve ser imediatamente abortada (reset); 

a SYN -segmento transporta uma requisição de abertura de conexão; 


o FIN -segmento transporta uma requisição de fechamento de conexão. 


Q) Code bits também são chamados de flags TCP. 


Os campos descritos acima foram definidos no RFC 793, que especifica o protocolo TCP. 


Posteriormente, o RFC 3168 modificou essa definição, acrescentando mais dois code bits: 
a Congestion Window Reduced (CWR) 


o Explicit Congestion Notification (ECE - ECN-Echo) 


O campo Options é uma lista variável de informações opcionais, sendo usado principalmente 
para definir o tamanho máximo dos segmentos (Maximum Segment Size - MSS) que podem 
ser recebidos por uma entidade TCP. Esta opção é sinalizada no segmento (SYN) que trans- 
porta um pedido de conexão. 


Sendo o campo Options variável, o campo Padding contém bits 0 que estendem o cabeçalho 
para torná-lo múltiplo de 32 bits. Observe que o campo Padding somente é usado quando o 
campo Options não é múltiplo de 32 bits. Saiba mais 


Os campos Source port e Destination port são usados na identificação das entidades comu- Para mais informações, 


consulte o RFC 3168: 


nicantes, enquanto os campos Sequence number, Acknowledgment number, Window e Urgent = o 
“The Addition of Explicit 


Congestion Notification 
importância destes campos, iremos estudá-los a seguir, bem como detalhes dos vários bits (ECN) to IP”. 


pointer são usados pelos mecanismos de controle de erro, sequência e fluxo. Em função da 





que compõem o campo Code hits. 
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Estrutura de conexão 


a Portas 
m Source port - porta associada ao processo origem. 
m Destination port - porta associada ao processo destino. 
a Endpoint 
m Definido pelo par endereço IP e porta. 
a Identifica de forma única cada porta ou ponto de comunicação na inter-rede. 
a Também conhecido como socket (linguagem C). 
o Conexão 
a Identificada de forma única por um par de endpoints. 
m Também conhecida como socket pair. 


m Cada endpoint pode participar de diversas conexões. 





m Sistema operacional deve assegurar que o par de endpoints da conexão é único. 


O endpoint identifica, de forma individual e única, um ponto de comunicação em toda a 
inter-rede, sendo representado pelo endereço IP da estação e a porta associada ao respec- 
tivo processo de aplicação. Da mesma forma que o protocolo UDP, o protocolo TCP também 
explora o conceito de porta. Portanto, segmentos transportam as portas associadas aos 
processos de aplicação origem e destino. Os campos Source port e Destination port são 
usados com este propósito. Como no UDP, no TCP cada um destes campos possui 16 bits, 


indicando que o maior número de porta possível é 65.535. 


Embora TCP e UDP adotem portas, os números das portas TCP são independentes dos 
números das portas UDP. Por exemplo, a porta TCP 10.000 e a porta UDP 10.000 podem ser 
usadas por diferentes processos de aplicação, executando na mesma estação. Observe que 
um mesmo número de porta não causa qualquer confusão, pois, primeiramente, o protocolo 


IP identifica o protocolo de transporte destino, baseado no campo Protocol dos datagramas IP. 


Apesar desta independência, na prática, se um determinado serviço é provido através de 
ambos os protocolos, o número da porta adotada é geralmente idêntico para os dois pro- 
tocolos. Por exemplo, a porta 80 é reservada para o serviço web nos protocolos TCP e UDP. 
Vale ressaltar que esta identidade é pura convenção, não existindo qualquer imposição por 


parte dos protocolos. 


Como vimos, uma entidade de transporte deve utilizar o par (endereço IP, porta) para iden- 
tificar cada endpoint em toda a inter-rede. No TCP, cada par (endereço IP, porta) define um 
ponto final de comunicação, comumente denominado endpoint ou socket. Portanto, cada 
endpoint identifica, de forma única, um ponto de comunicação em toda a inter-rede, ao qual 


está associado um processo de aplicação. 


Sendo o protocolo TCP orientado à conexão, ele deve identificar unicamente cada conexão, 
não apenas portas ou processos de aplicação individuais. No TCP, cada conexão é identifi- 


cada por um par de endpoints, também conhecido como socket pair. 
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172.16.1.5 192.168.10.1 


Porta 5000 








Figura 8.6 
Exemplo de 
(172.16.1.5, 5000) e (192.168.10.1, 80) (192.168.10.1, 25) e (10.1.1.1, 1800) conexão TCP. 
A Figura 8.6 mostra a identificação de duas conexões TCP: 
a A primeira conexão envolve o processo P1, executando na estação 172.16.1.5 e associado 
a porta 5.000, e o processo P2, executando na estação 192.168.10.1 e associado à porta 80. 
a Asegunda conexão envolve o processo P3, executando na estação 192.168.10.1 e associado 
a porta 25; e o processo P4, executando na estação 10.1.1.1 e associado à porta 1.800. 
172.16.1.5 192.168.10.1 10.1.1.1 
Figura 8.7 
Exemplo de 
(172.16.1.5, 5000) e (192.168.10.1, 80) (192.168.10.1, 80) e (10.1.1.1, 2000) conexão TCP (2). 


Observe que, em uma mesma estação, várias conexões podem ser estabelecidas simultane- 
amente. Além disso, um mesmo endpoint local pode participar de várias conexões dife- 
rentes com endpoints remotos, ou seja, conexões podem compartilhar endpoints. Por 
exemplo, na Figura 8.7, o endpoint (192.168.10.1, 80) participa de duas conexões. Embora um 
determinado endpoint possa participar de diversas conexões, localmente, cada sistema 
operacional deve assegurar que o par de endpoints de cada conexão é único, constituindo, 
portanto, uma identificação única para cada conexão. 


Demultiplexação de mensagens 


a Segmentos recebidos são associados às conexões, não apenas às portas. 
a Avalia o par de endpoints da conexão. 
a Portas origem e destino são obtidas do segmento recebido. 
m Endereços IP origem e destino são obtidos do datagrama IP. 
a Cada conexão possui um buffer de transmissão e um buffer de recepção em 


cada extremidade. 


O compartilhamento de endpoints parece tornar problemática a demultiplexação de mensa- 
gens destinadas à porta compartilhada. No entanto, o protocolo TCP associa os segmentos 
recebidos às respectivas conexões, não apenas às portas. Ou seja, o processo de demulti- 


plexação avalia o par de endpoints para apropriadamente identificar a respectiva conexão. 


No destino, para identificar a conexão que receberá a mensagem encapsulada no segmento, a 
entidade TCP associa os campos Source port e Destination port do segmento TCP com os ende- 


reços IP de origem e destino, recuperados do datagrama IP que transportou o segmento. 


Buffer 


Espaço de memória 
reservado para arma- 
zenar pacotes recebidos 
(buffer de recepção) 

ou a serem enviados 
(buffer de transmissão). 


Vimos que, no UDP, uma porta é geralmente implementada como uma fila interna do 
sistema operacional. No TCP, em função do compartilhamento de endpoints, cada conexão 


possui um buffer de transmissão e um buffer de recepção. Ao receber um segmento, o TCP 


verifica se existe a conexão associada ao segmento. Caso exista, a mensagem encapsulada 
é armazenada no final do buffer de recepção da conexão. Por outro lado, o processo de apli- 
cação associado àquela conexão acessa as mensagens armazenadas no buffer de recepção. 
Caso a conexão não exista, o protocolo TCP simplesmente descarta o segmento e gera um 
segmento reset (bit RST ligado) para a entidade TCP de origem, indicando que o segmento 


não referencia uma conexão válida. 


Mecanismos de controle 


a Controle de sequência 
a Fluxo de dados é tratado como uma sequência de bytes. 
a Cada byte possui um número de sequência. 


a Numeração não inicia sempre em 0, sendo negociada no estabelecimento da 


conexão. 


a Sequence number 





a Indica o número de sequência do primeiro byte de dados contido no segmento. 


Controle de sequência é o mecanismo que assegura que os dados recebidos por uma enti- 


dade estão na sequência em que foram transmitidos pela outra entidade. 


O protocolo TCP trata o fluxo de dados como uma sequência de bytes, que é dividida nos 
vários segmentos transmitidos. Conceitualmente, cada byte do fluxo de dados é sequen- 
cialmente numerado, possuindo, assim, um número de sequência. Ao invés de transportar 
os números de sequência de todos os bytes do fluxo de dados, cada segmento transporta 
apenas o número de sequência do primeiro byte de dados contido no segmento. Este 
número de sequência é informado no campo Sequence number do segmento, comumente 
denominado número de sequência do segmento. Logo, o número de sequência é um inteiro 
de 32 bits. Para permitir a transmissão de grandes volumes de dados, a numeração dos 


bytes volta ao valor O após atingir 237-1. 


Segmento 150 Segmento 200 Segmento 350 


Figura 8.8 
Controle de 
sequência TCP. 


A Figura 8.8 mostra um exemplo de divisão de uma sequência de bytes em segmentos, 
destacando o número de sequência (Sequence number) de cada segmento enviado. Observe 
que cada segmento informa apenas o número de sequência do primeiro byte de dados 
contido no segmento. Além disso, é importante observar que a numeração do fluxo de 
dados não necessariamente é iniciada em 0 e os segmentos não transportam a mesma 
quantidade de dados. Como veremos adiante, o número de sequência inicial é negociado no 


estabelecimento da conexão. 


Na entidade TCP destino, os números de sequência dos segmentos são usados pelo meca- 
nismo de controle de sequência para restabelecer a sequência original do fluxo de dados, recu- 
perando a ordem correta dos segmentos recebidos e descartando os segmentos duplicados. 
No exemplo da Figura 8.8, se a entidade TCP destino receber os segmentos com números de 
sequência 150, 350, 200 e 350, ela recupera a sequência original 150, 200 e 350, trocando a 
ordem dos segmentos 350 e 200, bem como descartando o segmento 350 duplicado. 
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Controle de erros 


a Reconhecimento positivo 

a Destino retorna uma mensagem indicando o recebimento correto do segmento. 

= Reconhecimento pode pegar carona nos segmentos de dados do fluxo inverso. 
a Reconhecimento cumulativo 

m Diversos segmentos consecutivos podem ser reconhecidos em uma única mensagem. 
a Acknowledgment number 

a Indica o número de sequência do próximo byte que espera receber. 

a Indica o correto recebimento dos bytes com número de sequência inferior. 

m Bit ACK deve estar ativo. 
a Retransmissão 

a Origem adota um temporizador para cada segmento transmitido. 


m Segmento é retransmitido quando a origem não recebe o reconhecimento antes 
de expirar o temporizador. 


m O temporizador é reativado em cada retransmissão. 


O controle de erros é o mecanismo que realiza a detecção de erros em dados recebidos, 
e, em seguida, ativa procedimentos para correção destes erros. Na prática, geralmente, a 
correção é realizada através da retransmissão dos dados. 


O controle de erros é dividido em detecção e correção de erros. A detecção de erros 
assegura a integridade dos segmentos, enquanto a correção de erros recupera segmentos 
perdidos ou corrompidos. Como vimos, o protocolo TCP implementa a detecção de erros 
usando o campo Checksum, onde segmentos corrompidos são simplesmente descartados. 


Para correção de erros, o protocolo TCP adota a técnica de reconhecimento positivo 
cumulativo com retransmissão. Nesta técnica, a entidade TCP destino retorna mensagens 
de reconhecimento positivo para a entidade TCP origem, indicando o correto recebimento 
de segmentos. A mensagem de reconhecimento transporta, no campo Acknowledgment 
number do segmento, o número de sequência do próximo byte que a entidade TCP destino 
(origem do reconhecimento) espera receber, indicando o correto recebimento dos bytes com 
número de sequência inferior. O campo Acknowledgment number é válido apenas quando o 
bit ACK está ativo. 


No exemplo da Figura 8.9, após receber o segmento 150, que transporta 50 bytes de dados 
(byte 150 até byte 199), a entidade TCP destino retorna um segmento de reconhecimento 


que possui o valor 200 no campo Acknowledgment number, indicando o correto recebimento 


a 

T Figura 8.9 
S do fluxo de dados até o byte 199 e sinalizando que espera os dados a partir da posição 200. Controle de erros. 
ES 
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a 
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È Seq number 150 Seq number 200 Seq number 350 
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Para reduzir o número de mensagens de reconhecimento, ao invés de retornar uma men- 
sagem de reconhecimento para cada segmento recebido, a entidade TCP destino pode enviar 
um único reconhecimento para indicar a correta recepção de vários segmentos consecutivos. 


Diz-se, então, que o TCP adota reconhecimento cumulativo. 


Por exemplo, na Figura 8.9, após receber os segmentos 150, 200 e 350, ao invés de enviar 
um reconhecimento para cada um destes segmentos (como indicado na figura), a entidade 
TCP de destino pode enviar um único reconhecimento que possui o valor 450 no campo 
Acknowledgment number, indicando o correto recebimento do fluxo de dados até o byte 449 


e sinalizando que aguarda os dados a partir da posição 450. 


Sendo a conexão TCP full-duplex, ao invés de gerar segmentos que apenas sinalizam os 
reconhecimentos, as entidades TCP podem enviar estes reconhecimentos em segmentos de 
dados do fluxo inverso. Ou seja, os reconhecimentos podem pegar carona (piggybacking) 
em segmentos de dados do fluxo inverso, melhorando a eficiência do protocolo. Para tal, 
segmentos que transportam reconhecimentos devem ativar o bit ACK e incluir o número de 


sequência do próximo byte esperado no campo Acknowledgment number. 


Considerando que segmentos podem ser perdidos ou descartados, o protocolo TCP utiliza a 
retransmissão para garantir a entrega do fluxo de dados. Quando uma entidade TCP origem 
envia um segmento, ela mantém uma cópia dos dados deste segmento e ativa um tempo- 
rizador, esperando que a entidade TCP destino envie um reconhecimento dos dados. Se o 
reconhecimento é recebido antes do temporizador expirar, a cópia dos dados é descartada. 
Caso contrário, a entidade TCP origem assume que o segmento foi perdido ou descartado 
e retransmite os dados em um novo segmento. Em cada retransmissão, o temporizador é 


reativado para aguardar pelo reconhecimento. 


A adoção de reconhecimento cumulativo permite que uma entidade TCP origem envie vários 
segmentos consecutivos, antes de receber qualquer reconhecimento. No entanto, o TCP 
deve adotar mecanismos de controle de fluxo para regular a comunicação entre duas enti- 


dades, evitando que uma entidade envie mais dados do que a outra é capaz de receber. 


Controle de fluxo 


o Janela deslizante : 


a Entidades negociam o número de bytes adicionais que podem ser recebidos a 


partir do último reconhecimento. 
a Destino define o tamanho de sua janela de recepção em cada segmento. 
a Origem atualiza o tamanho da janela de transmissão a cada reconhecimento. 


a Reconhecimentos deslocam a janela de transmissão da origem para o primeiro 


byte sem reconhecimento. 


o Window 





a Sinaliza o tamanho da janela de recepção da entidade em cada segmento enviado. 


Controle de fluxo é o mecanismo que regula e compatibiliza a taxa de transmissão de dados 
entre duas entidades, assegurando que uma entidade somente envia dados quando a outra 


é capaz de recebê-los. 


Para controle de fluxo, o protocolo TCP adota a técnica de janela deslizante (sliding window). 
Nesta técnica, as entidades TCP comunicantes informam, uma para a outra, o número de 
bytes adicionais que podem ser recebidos a partir da posição do último reconhecimento. 


Este número de bytes define o tamanho da janela de recepção da entidade TCP destino. 
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Com base nesta informação, a entidade TCP origem atualiza sua janela de transmissão, ou 
seja, define o número de bytes que pode enviar antes de receber outro reconhecimento. 








Ack number 300 
Figura 8.10 
Controle de 
deslizante. 


A técnica de janela deslizante recebe esta denominação porque, após receber um reconheci- 
mento, a janela de transmissão da entidade TCP de origem desloca-se, passando a ser iniciada 
no primeiro byte do fluxo que ainda não obteve uma mensagem de reconhecimento. Por 
exemplo, na Figura 8.10, uma janela de transmissão de 400 bytes, iniciando na posição 100, é 
deslocada de 200 bytes após o recebimento de um segmento, cujo Acknowledgement number 
seja 300. Vale ressaltar que, após receber este reconhecimento (ACK 300), a entidade TCP de 


origem pode transmitir mais 200 bytes. 


O tamanho da janela de recepção de uma conexão é informado pela entidade TCP no campo 
Window de cada segmento. Sendo este campo de 16 bits, o tamanho da janela é limitado 

a 65.535 bytes. Vale ressaltar que o protocolo TCP define uma opção que permite o incre- 
mento deste tamanho máximo da janela. Observe que, sendo ajustada a partir do campo 
Window de cada segmento recebido da estação destino, a janela de transmissão da estação 
origem representa o número de bytes que a estação destino pode armazenar em seu buffer 
de recepção. Portanto, o mecanismo de janela deslizante evita que segmentos enviados 


sejam descartados no destino por falta de espaço no buffer de recepção. 


O mecanismo de janela deslizante também é utilizado para evitar congestionamento na rede. 
Neste caso, a entidade TCP monitora os retardos associados aos reconhecimentos. Geral- 
mente, incrementos nos retardos representam situações de congestionamento na rede. Para 
evitar congestionamento, a entidade TCP reduz a taxa de transmissão, diminuindo o tamanho 
da janela de transmissão, quando detecta incrementos nos retardos dos reconhecimentos. 


Estabelecimento de conexão 
o Estabelecimento de conexão 
= Three-way handshake 


a Negocia e sincroniza o valor inicial dos números de sequência em ambas 


as direções. 
o Urgent pointer 
m Sinaliza a posição na porção de dados em que terminam os dados urgentes. 
m Bit URG deve estar ativo. 
a Mecanismo push 
m Força a geração de um segmento com os dados já presentes no buffer. 
m Não aguarda o preenchimento do buffer. 


m Segmentos gerados pelo mecanismo push são marcados com a ativação do bit PSH. 


Figura 8.11 
Abertura de 
conexdo TCP. 


Quando dois processos desejam se comunicar, as respectivas entidades TCP devem, primei- 
ramente, estabelecer uma conexão. O protocolo TCP adota o algoritmo Three-way handshake 
para estabelecer uma conexão, negociando e sincronizando o valor inicial dos números de 


sequência dos fluxos de dados, conforme mostrado na Figura 8.11. 


Entidade A Entidade B 
(requisitante) (requisitada) 


SYN SEQ=x 
SYN SEQ=x 


SYN SEQ=y ACK=x+1 


SYN SEQ=y ACK=x+1 


SEQ=x+1ACK=y+1 
SEQ=x+1ACK=y+1 





Inicialmente, a entidade requisitante envia um segmento SYN, que possuio bit SYN ativado, 
indicando um pedido de abertura de conexão. O campo Sequence number deste segmento 
contém o número de sequência inicial (x) escolhido pela entidade requisitante para esta 
conexão. Após o estabelecimento da conexão, o valor x+1 é o número de sequência do pri- 


meiro byte do fluxo de dados gerado pela entidade requisitante. 


Após receber e aceitar o pedido de conexão, a entidade requisitada envia um segmento 
SYN, cujo campo Sequence number contém o número de sequência inicial (y) escolhido pela 
entidade. Além disso, o campo Acknowledgement number indica que a entidade requisitada 
aguarda o primeiro byte (x+1) do fluxo de dados gerado pela entidade requisitante. De forma 
semelhante, o valor y+1 é o número de sequência do primeiro byte do fluxo de dados gerado 


pela entidade requisitada. 


Por fim, a entidade requisitante envia um segmento à entidade requisitada, informando que 
ambos aceitam a conexão estabelecida. Neste segmento, o campo Acknowledgement number 
indica que a entidade requisitante aguarda o primeiro byte (y+1) do fluxo de dados gerado 


pela entidade requisitada. 


> 
Exercício de fixação iG 
Abertura de conexdo TCP 


1. Vamos ativar o Wireshark, como fizemos anteriormente, só que desta vez para configurar 
um filtro de captura. Na tela inicial do Wireshark, em vez de selecionar o botão “Start”, 


vamos selecionar o botão “Options” na interface de rede local. 


Teremos então a tela a seguir. Na janela “Capture Filter:”, digite o filtro: tcp port 80 and host 
“o endereço IP de sua estação” (sem as aspas). No exemplo usamos o IP: 192.168.100.103, 
conforme mostrado na Figura 8.12. Observe que a janela de filtro de captura fica com o fundo 
verde quando a sintaxe do comando está correta e vermelho quando não está correta. 


Essa sintaxe é compatível com a sintaxe adotada pelo programa Tcpdump. 


X Capítulo 8 - Camada de transporte 


321 


X Arquitetura e Protocolos de Rede TCP-IP 


322 


Wireshark: Capture Options 





Capture 


Interface: Local | Microsoft: \Device\NPF_{DE 
IP address: fe80::d0ce:722c:edal:17d6, 192.168.100.103 
Link-layer header type: Ethernet [x] 


(V| Capture packets in promiscuous mode 





| Capture packets in pcap-ng format Figura 8.12 


Limit each packet to 65535 = bytes Opções de captura 











de pacotes do 
Capture Filter: | | tcp port 80 and host 192.168.100.103 Wireshark. 


Em seguida clique em “Start” para iniciar a captura; porém, somente serão capturados 





os pacotes de/para a sua estação e que sejam destinados/recebidos da porta TCP 80. 


Os demais pacotes IP serão descartados. 


2. Abra o navegador instalado na sua máquina e digite o seguinte URL: www.uol.com.br. 


Aguarde alguns minutos até que todas as operações tenham sido concluídas. Feche a janela 
do navegador e aguarde mais um minuto, para que as conexões TCP ainda abertas possam 
ser fechadas. Volte para a janela do Wireshark (que ficou aberta) e só então termine a 
captura de pacotes clicando no quarto ícone da esquerda para a direita da barra de ferra- 


mentas (Stop the running live capture). 


A tela do Wireshark deverá ser semelhante à mostrada na Figura 8.13. 


No. lime Source Destination Protocol Length Into 
1 0.000000 192.168.100.103 200.14/.3.191 TCP 66 50288 > http [SYN] Seq-0 Win-8192 Len-0 MSS-1460 WS-4 SACK PERM-1 
2 0.029970 200.14/.3.191 192.168.100.103 TCP 66 http > 50288 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1400 SACK_ 
3 0.030178 192.168.100.103 200.14/.3.191 TCP 54 50288 > http [ACK] Seg=1 Ack=1 Wine1/520 Len-0 
4 0.031754 192.168.100.103 200.14/.3.191 HTTP 443 GET /h/2011/styles.css HTTP/1.1 
5 0.060558 200.147.3.191 192.168.100.103 TCP 54 http > 50288 [ACK] Seq-1 Ack=390 Win-6912 Len-0 
6 0.064841 200.147.3.191 192.168.100.103 HTTP 1514 HTTP/1.1 200 OK (text/css) 
7 0.065403 200.147.3.191 192.168.100.103 HTTP 1514 Continuation or non-liTTP traffic 
8 0.065542 192.168.100.103 200.147.3.191 TCP 54 50288 > http LACK] Seq=390 Ack=2921 win-17520 Len-0 
9 0.065828 200.147.3.191 192.168.100.103 HTTP 1514 Continuation or non-liTTP traffic 
10 0.066039 200.147.3.191 192.168.100.103 HTTP 1514 Continuation or non-HTTP traffic 
11 0.066152 192.168.100.103 200.147.3.191 TCP 54 50288 > http [ACK] Seq=390 Ack=5841 win=17520 Len=0 
12 0.068395 200.147.3.191 192.168.100.103 HTTP 1514 Continuation or non-HTTP traffic 
13 0.068435 200.147. 3.191 192.168.100.103 HTTP 1514 Continuation or non-HTTP traffic 
14 0.068455 200.147.3.191 192.168.100.103 HTTP 1514 Continuation or non-HTTP traffic 
15 0.068516 200.147. 3.191 192.168.100.103 HTTP 865 Continuation or non-HTTP traffic 
16 0.069416 197.168.100.103 200.147.3.191 TCP 54 50288 > http [ack] Seq=390 ack=11033 win=17570 Len=0 
17 0.294557 192.168.100.103 200.147.3.191 TCP 54 50288 > http [FIN, ACK] Seg=390 ack=11033 win=17520 Len=0 
18 0.324809 200.147.3.191 192.168.100.103 TCP 54 http > 50288 [ack] Seq=11033 ack=391 win=6912 Ler=0 


mm 


a Frame 1: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) 

= Ethernet II, Src: HomHaiPr_60:a2:1a (00:24:20 :60:a2:1a), Ost: Cisco-Li c8:b5:2a (00:18:39:c8:b5:2a) 

4 Internet Protocol version 4, Src: 192.168.100.103 (192.168.100.103), Dst: 200.147.3.191 (200.147.3.191) 
+ Transmission control protocol, src port: 50288 (50288), ost Port: http (80), seq: O, Len: O 


Observe na sua tela que foram abertas diversas conexões TCP para a carga da página inicial do Figura 8.13 
Pacotes capturados 
durante o acesso a 
www.uol.com.br. 


URL acessado, de modo a obter um melhor desempenho. As telas de todos os alunos serão 
semelhantes, mas diferentes nos detalhes, endereços e portas envolvidos na conexão TCP. Para 
facilitar a compreensão dos detalhes operacionais da conexão TCP, será necessário trabalhar com 
um arquivo capturado previamente, para que todos tenham exatamente os mesmos valores. 

O arquivo em questão chama-se “Sessao8 Captural.pcap” e está mostrado na Figura 8.13. 


3. Uma vez aberto o arquivo mencionado, a tela deverá ser igual à mostrada na Figura 8.13, onde 
aparecem todos os 18 registros do arquivo. Todos os registros se referem à mesma conexão 
TCP, que usa as portas: 80 (servidor) e 50288 (cliente). Para conseguir isso, foi necessário usar o 
seguinte filtro: “tcp.port == 50288" (sem as aspas). Essa sintaxe é diferente da sintaxe adotada 
pelo Tcpdump no filtro de captura, porque é uma sintaxe proprietária do programa Wireshark 
que usa interface gráfica (ao contrário do Tcpdump, que usa linha de comando). 


4. Vamos agora analisar os pacotes envolvidos na abertura desta conexdo TCP, que sdo 


exatamente os 3 primeiros pacotes (1 a 3), mostrados na Figura 8.14. 





No. Time Source Destination Protocol Length Info 
1 0.000000 192.168.100.103 200.147.3.191 TCP 66 50288 > http [SYN] Seq=0 win=8192 Len=0 MSS= 
2 0.029970 200.147.3.191 192.168.100.103 TCP 66 http > 50288 [SYN, ACK] Seq=0 Ack=1 win=5840 
3 0.030178 192.168.100.103 200.147.3.191 TCP 54 50288 > http [ACK] Seq=1 Ack=1 win=17520 Len: 





< m 


E Frame 1: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) 
Œ Ethernet II, Src: lontiaiPr_60:a2:1a (00:24:2c:60:a2:1a), Dst: Cisco-Li_c8:b5:2a (00:18:39:c8:b5:2a) 
E Internet Protocol Version 4, Src: 192.168.100.103 (192.168.100.103), Dst: 200.147.3.191 (200.147.3.191) 


= Transmission Control | t: 50288 eq: 0, Len: 














Figura 8.14 
Pacotes referentes 
ao three-way- Eles mostram o processo de abertura de conexão TCP (three-way-handshake), que é realizado 
handshake 
capturados. 


Observe que os 3 pacotes são pacotes do protocolo TCP, que não tem dados da aplicação. 


ANTES do envio dos dados da aplicação. 


5. Reproduzimos a seguir a Figura 8.11, que mostra o mecanismo da abertura de conexão TCP. 


Entidade A Entidade B 
(requisitante) (requisitada) 


SYN SEQ=x 
SYN SEQ=x 


SYN SEQ=y ACK=x+1 


SYN SEQ=y ACK=x+1 


SEQ=x+1ACK=y+1 
SEQ=x+1ACK=y+1 





O primeiro pacote é enviado pelo cliente (Entidade A - requisitante) e tem o code bit SYN 
ligado para solicitar a abertura da conexão TCP no sentido cliente -> servidor, e informa ao 
servidor (Entidade B - requisitada) o seu contador de octetos enviados (SEQ=x), a partir do 
qual será feita a contagem dos octetos (inicialização do contador de octetos enviados). 


Note que o Wireshark aponta o valor zero (Seg: 0) na linha do TCP selecionada na figura, mas 
Figura 8.15 sabemos que esse valor é um valor randômico de 32 bits. Só é possível saber o valor real 
Primeiro pacote 


da abertura de 
conexão TCP. indica zero porque ele é, na realidade, o zero relativo da contagem de octetos enviados. 


desse contador detalhando o cabeçalho do TCP, conforme mostra a Figura 8.15. O Wireshark 


Frame 1: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) 
Ethernet II, Src: HonHaiPr_60:a2:1a (00:24:2c:60:a2:1a), Dst: Cisco-Li c8:b5:2a (00:18:39:cé 
Internet Protocol version 4, Src: 192.168.100.103 (192.168.100.103), Dst: 200.147.3.191 (20 





HEHE 














source port: 50288 (50288) 
Destination port: http (80) 
[stream index: 0] 


Sequence number: O (relative sequence number) 


Header length: 32 bytes 
@ (Flags: 0x02 (SYN) 
window size value: 8192 
[calculated window size: 8192] 
Œ Checksum: 0x799e [validation disabled] 
Œ Options: (12 bytes) 














0000 00 18 39 c8 b5 2a 00 24 2c 60 a2 ia 08 004500 ..9..*.$ ,`....E. 
0010 00 34 19 9d 40 00 80 06 ef c4 cO a8 64 67 c8 93 .4..@... ....dg.. 
0020 03 bf c4 70 00 50 00 00 00 00 80 02 a... p. PREH. ..... 
0030 20 00 79 9e 00 00 02 04 05 b4 01 03 03 02 01 OL uy... seer... 
0040 04 02 E 
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6. Nesta figura foi selecionado o campo “Sequence number: 0 (relative sequence number)”. 
Note que o Wireshark adverte que é um “número de sequência relativo”. O valor em hexa- 
decimal aparece em destaque na janela inferior e vale em hexadecimal: x = fd a8 21 ac. 
Em decimal é: x = 4255654316. 


Observações importantes: 


o O endereço IP da origem é o do cliente: 192.168.100.103; 
o O endereço IP de destino é o do servidor: 200.147.3.191; 


a Portas TCP de origem e destino, respectivamente: 50288 e 80; 


Flags: 0x02 (SYN) (significa que o code bit SYN está ligado). 


7. Vamos agora visualizar os detalhes do pacote 2, que deve ser o pacote enviado pelo 
servidor, no qual ele também liga o code bit SYN para solicitar a abertura da conexão TCP 
no sentido servidor -> cliente (lembre-se de que a conexão TCP é full-duplex), aceita o 
pedido de abertura de conexão TCP do cliente, inicializa seu contador de octetos enviados 
(SEQ=y) e reconhece o contador do cliente (x), indicando seu contador de octetos rece- 
bidos ACK=x+1 (Figura 8.11). Esse pacote está detalhado na Figura 8.16. 


No. Time Source Destination Protocol Length Info 
1 0.000000 192.168.100.103 200.147.3.191 TCP 66 50288 > http [SYN] Seq=0 win=8192 Len=0 M 
2 0.029970 200.147.3.191 192.168.100.103 TcP 66 http > 50288 [SYN, ACK] Seq=0 Ack=1 win=5 
3 0.030178 192.168.100.103 200.147.3.191 TCP 54 50288 > http [ACK] Seq=1 Ack=1 win=17520 





4 | uw 


E 


Frame 2: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) 
) Ethernet II, Src: Cisco-Li c8:b5:2a (00:18:39:c8:b5:2a), Dst: HonHaiPr 60:a2:1a (00:24:2c:60:a2:1a) 
| Internet Protocol version 4, src: 200.147.3.191 (200.147.3.191), Dst: 192.168.100.103 (192.168.100.1 
| Transmission Control Protocol, Src Port: http (80), Dst Port: 50288 (50288), Seq: 0, Ack: 1, Len: 0 

Source port: http (80) 

Destination port: 50288 (50288) 

[stream index: 0] 

Acknowledgement number: 1 (relative ack number) 

Header length: 32 bytes 
Flags: 0x12 (SYN, ACK) 

Window size value: 5840 

[calculated window size: 5840] 
E Checksum: Oxc7f7 [validation disabled] 


0000 00 24 2c 60 a2 1a 00 18 39 c8 b5 2a 08 00 45 00 oao aena Sea a 
0010 00 34 00 00 40 00 35 06 54 62 c8 93 03 bf cO a8 04.66.56 a 


0020 64 67 00 50 c4 70 (CERT: fd a8 21 ad 80 12  dg.P.pEREM..'... 
4 05 


OF 





0030 16 dO c7 f7 00 00 02 O 4 010104 020103 ........ ecc. 

0040 03 07 

O contador de octetos enviados do servidor (SEQ=y) tem o valor em hexadecimal: Figura 8.16 

y = 71 02 49 be, e em decimal: y = 1895975358. Segundo pacote 


da abertura de 
conexão TCP. 
® Observe que o contador de octetos enviados do cliente deve bater com o contador 


de octetos recebidos do servidor, e vice-versa. 


Observações importantes: 


o O endereço IP da origem é o do servidor: 200.147.3.191; 

a O endereço IP de destino é o do cliente: 192.168.100.103; 

o Portas TCP de origem e destino, respectivamente: 80 e 50288; 

o Flags: 0x12 (SYN, ACK) - significa que os code bits SYN e ACK estão ligados; 


a Acknowledgement number: 1 (relative ACK number) efetua o reconhecimento do con- 
tador de octetos enviados do cliente (x), indicando o valor x+1, conforme podemos cons- 
tatar na última janela (em hexadecimal: x+1 = fd a8 21 ad; em decimal: x+1 = 4255654317). 


Se x é o contador dos octetos enviados pelo cliente para o servidor, e o pacote 1 não enviou 
nenhum octeto de dados (assim como os pacotes 2 e 3) por que, no reconhecimento efetuado 


pelo servidor, o contador foi incrementado de 1 (x+1)? 








Note que o Wireshark informa na linha referente ao protocolo TCP o tamanho do campo de 


dados “Len: 0”. Nesses 3 primeiros pacotes o valor Len é sempre zero. 


8. Finalmente, vamos visualizar os detalhes do pacote 3, que deve ser o pacote enviado pelo 
cliente, no qual ele aceita o pedido de abertura de conexão TCP do servidor, e confirma 
os valores dos contadores de octetos de ambos os lados (SEQ=x+1, ACK=y+1). Esse pacote 


está detalhado na Figura 8.17. 


No. Time Source Destination Protocol Length Info 
1 0.000000 192.168.100.103 200.147.3.191 TCP 66 50288 > http [SYN] Seq=0 win=8192 Len=0 à 
2 0.029970 200.147.3.191 192.168.100.103 TCP 66 http > 50288 [SYN, ACK] Seq=0 Ack=1 win=: 
3 0.030178 192.168.100.103 200.147.3.191 TCP 54 50288 > http [ACK] Seq=1 Ack=1 win=17520 





< | mM 


= Frame 3: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) 
Œ Ethernet II, Src: HonHaiPr_60:a2:1a (00:24:2c¢:60:a2:1a), Dst: Cisco-Li_c8:b5:2a (00:18:39:c8:b5:2a) 
= Internet Protocol version 4, Src: 192.168.100.103 (192.168.100.103), Dst: 200.147.3.191 (200.147.3.: 
E Transmission Control Protocol, Src Port: 50288 (50288), Dst Port: http (80), Seq: 1, Ack: 1, Len: O 
Source port: 50288 (50288) 
Destination port: http (80) 
[stream index: 0] 
Sequence number: 1 (relative sequence number) 
Acknowledgement number: 1 relative ack number 
Header length: 20 bytes 
@ Flags: 0x10 (ACK) 
window size value: 4380 
{calculated window size: 17520] 
[window size scaling factor: 4] 


0000 00 18 39 c8 b5 2a 00 24 2c 60 a2 la 08 00 45 00 ..9..*.$ ,` 
0010 00 28 19 9f 40 00 80 06 ef ce cO a8 64 67 c8 93 —...@... 
0020 03 bf c4 70 00 50 fd a8 21 ad PEJE 50 10 ...p.P.. 
0030 11 1c Oe 7e 00 00 ae eae 





Figura 8.17 O contador de octetos recebidos do cliente (ACK=y+1) tem o valor em hexadecimal: 


Terceiro pacote y = 74 02 49 bf, e em decimal: y = 1895975359. 
da abertura de 


conexão TCP. observações importantes: 


o O endereço IP da origem é o do cliente: 192.168.100.103; 

o O endereço IP de destino é o do servidor: 200.147.3.191; 

o Portas TCP de origem e destino, respectivamente: 50288 e 80; 
a Flags: 0x10 (ACK) - significa que o code bit ACK está ligado. 


Se y é o contador dos octetos enviados pelo servidor para o cliente e o pacote 2 não enviou 
nenhum octeto de dados (bem como os pacotes 1 e 3), por que no reconhecimento efetuado 


pelo cliente o contador foi incrementado de 1 (y+1)? 








Nesse ponto, a conexão TCP está estabelecida nos dois sentidos, e os contadores de octetos 
de ambos os lados (x e y) estão inicializados e devidamente reconhecidos; portanto, os 


dados da aplicação podem ser enviados a partir do pacote 4, como veremos adiante. 
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Transferência de dados 


Após estabelecer uma conexão, os respectivos processos podem enviar e receber dados 
simultaneamente. Os mecanismos de controle de erro, sequência e fluxo atuam durante 
esta fase de transferência de dados, assegurando a entrega dos fluxos de dados em ambas 
as direções. Vale ressaltar que, para aumentar a eficiência do protocolo contra variações dos 
retardos da inter-rede, o TCP adota mecanismos de ajuste dinâmico dos temporizadores de 
retransmissão e tamanho das janelas de transmissão e recepção. O escopo deste curso não 
inclui o detalhamento destes mecanismos. 


Embora o protocolo TCP seja orientado a fluxo, em algumas situações, um processo de 
aplicação pode necessitar enviar dados urgentes para o outro processo, que precisam ser 
tratados por este outro processo, antes dos bytes que já estão em seu buffer de recepção. 
Para tratar o envio de dados urgentes, o TCP usa o bit URG e o campo Urgent pointer. Quando 
o bit URG está ligado, o campo Urgent pointer especifica a posição na porção de dados onde 
terminam os dados urgentes. Portanto, o campo Urgente pointer somente é válido quando o 
bit URG está ligado. 


Como já sabemos, internamente, a entidade TCP decide como dividir o fluxo de dados em 
segmentos. No entanto, em aplicações interativas, é interessante o envio instantâneo dos 
dados para o outro processo. Para tal, o TCP provê a operação push, que força a entidade TCP 
a gerar um segmento com os dados presentes no buffer de transmissão, sem esperar pelo seu 


preenchimento. Segmentos enviados pelo mecanismo push são marcados pelo bit PSH ligado. 


® 
Exercício de fixação 2 _G 
Envio de dados em conexdo TCP 


1. Os dados foram enviados através dos pacotes 4 a 16 (ver Figura 8.14). Vamos analisar 
esses pacotes e descobrir como funcionam os contadores de octetos de ambos os lados. 
A Figura 8.18 mostra o pacote 4 em detalhe. 


No. Time Source Destination Protocol Length Info 
4 0.031754 192.168.100.103 200.147.3.191 HIIP 443 Gt! /h/2011/styles.css HIIP/1.1 


4 m 


= Frame 4: 443 bytes on wire (3544 bits), 443 bytes captured (3544 bits) 
= Ethernet II, Src: HonHaipr 60:a2:1a (00:24:2c:60:a2:1a), Dst: Cisco-Li_c8:b5:2a (00:18:39:c8:b5:2a) 
= Internet Protocol version 4, Src: 192.168.100.103 (192.168.100.103), Dst: 200.147.3.191 (200.147.3.191) 
Transmission Control Protocol, src Port: 50288 (50288), Dst Port: http (80), Seq: 1, Ack: 1, Len: 389 
Source port: 50288 (50288) 
Destination port: http (80) 
[stream index: 0] 


Sequence number: 1 (relative sequence number) 
[Next sequence number: 390 (relative sequence number)] 
Acknowledgement number: 1 (relative ack number) 


Header length: 20 bytes 
= Flags: Ux18 (PSH, ACK) 
window size value: 4380 
[calculated window size: 17520] 
(window size scaling factor: 4] 
= Checksum: 0x2c30 [validation disabled] 
=| [SEQ/ACK analysis] 
[Bytes in flight: 389] 
+ Hypertext Transfer Protocol 





Observações importantes: Figura 8.18 
Pacote numero 4 
a Sentido do pacote: cliente -> servidor; de dados. 


a Portas de origem e destino: 50288 e 80, respectivamente; 
o SEQ=1 - contador de octetos enviados do cliente; 


a ACK=7 - contador de octetos recebidos do cliente (não confundir com o code bit ACK); 


o [Next sequence number: 390 (relative sequence number)] - número meramente informa- 
tivo, fornecido pelo Wireshark a titulo de orientação; a diferença entre esse número e o 
contador de enviados pelo cliente deve refletir a quantidade de octetos enviados neste 
pacote (390 - 1 = 389). 


o Flags: 0x18 (PSH, ACK) - indica que os code bits PSH e ACK estão ligados; o uso do PSH 
pelo TCP do cliente é para informar ao TCP do servidor que os dados deste pacote devem 
ser IMEDIATAMENTE enviados para a aplicação destino, sem esperar o preenchimento 
do buffer de recepção do TCP; a razão disso fica clara: este pacote carrega um pedido de 
página web (operação GET do protocolo HTTP), de forma que o cliente não tem mais nada 


para enviar neste momento e vai ficar aguardando o envio da página web solicitada. 


o [SEQ/ACK analysis] [Bytes in flight: 389] - esta informação fornecida pelo Wireshark é 
apenas a título de orientação; o Wireshark analisa os contadores e informa que foram 
enviados 389 octetos “in flight”, o que significa que foram enviados, mas ainda não 
reconhecidos pelo servidor. Portanto, o contador de octetos enviados ainda não pode 
ser atualizado; o cliente tem que aguardar a confirmação (ver figuras 8.8, 8.9 e 8.10, que 


descrevem os mecanismos de controle de sequência, erro e fluxo). 


o Len: 389 - esta informação está na linha onde aparece o protocolo TCP e indica a quanti- 


dade de octetos de dados enviados neste pacote. 


o Aúltima linha da janela informa que existem dados do protocolo HTTP; observe que na 
primeira janela onde aparece o pacote número 4, o protocolo indicado é o HTTP, porque 


o Wireshark informa apenas o protocolo de camada mais alta presente no pacote. 


2. Vamos analisar agora o pacote de dados número 5 enviado pelo servidor em resposta ao 


pacote número 4, que solicitava uma página web, conforme mostra a Figura 8.19. 


No. Time Source Destinatio Protocol Length Info 


060558 200.147.3.191 68. 10( 54 






4 m 


= Frame 5: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) 
7 Ethernet II, src: Cisco Li_c8:b5:2a (00:18:329:c8:b5:2a), Dst: HonHaiPr_60:a2:1a (00:24:2c:60:a2:1a) 
Internet Protocol Version 4, Src: 200.147.3.191 (200.147.3.191), Dst: 192.168.100.103 (192.168.100.103) 
= Transmission Control Protocol, src Port: http (80), Nst Port: 50288 (507288), Seq: 1, Ack: 390, ten: 0 
Source port: http (80) 
Destination port: 50288 (50288) 
[stream index: 0] 
Sequence number: 1 (relative sequence number) 
Acknowledgement number: 390 (relative ack number) 
Header length: 2U bytes 
Flay»: 0x10 (ACK) 
window size value: 54 
[calculated window size: 6912] 
[Window size scaling factor: 128] 
Checksum: Oxtddf [validation disahled] 
[SEQ/ACK analysis] 
[this is an ACK to the seqment in frame: 4] 
[The RTT to ACK the segment was: 0.028804000 seconds] 


3] 


+ 


E 





Figura 8.19 Observações importantes: 
Pacote número 5 
de dados. mw Sentido do pacote: servidor -> cliente; 


o Portas de origem e destino: 80 e 50288, respectivamente; 
o SEQ = 1 - contador de octetos enviados do servidor; 
a ACK = 390 - contador de octetos recebidos do servidor; 


o Flags: 0x10 (ACK) - indica que o code bit ACK está ligado, portanto, este pacote deve ser 
uma confirmação de recebimento de um pacote anterior (qual pacote?); veja a explicação 


no próximo item. 
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o [SEQ/ACK analysis] [This is an ACK to the segment in frame : 4] - esta informação fornecida 
pelo Wireshark é apenas a título de orientação; o Wireshark analisa os contadores e informa 


que este segmento confirma o recebimento do segmento contido no quadro 4 recebido. 


a Observe que na primeira janela onde aparece o pacote número 5, o protocolo indicado é 


o TCP, o que significa que não existem dados da aplicação neste pacote (ver o Len: 0). 


Uma vez que o servidor confirmou ter recebido os 389 octetos enviados pelo cliente no pacote 


número 4, o contador de octetos enviados pelo cliente deverá ser atualizado de acordo. 


Figura 8.20 
3. Vamos analisar o pacote de dados número 6 enviado pelo servidor, conforme mostra a Pacote número 6 
figura 8.20. de dados. 
No. Time Source Destination Protocol Length Info 
6 0.064841 200.147.3.191 192.168.100.103 HTTP 1514 HTTP/1.1 200 OK (text/css) 


m 


Frame 6: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits) 
Ethernet II, Src: Cisco-Li_c8:b5:2a (00:18:39:c8:b5:2a), Dst: HonHaiPr_60:a2:1a (00:24:2c:60:a2:1a) 
Internet Protocol version 4, Src: 200.147.3.191 (200.147.3.191), Dst: 192.168.100.103 (192.168.100.103) 
Transmission Control Protocol, src Part: http (80), Dst Port: 50288 (50788), Seq: 1, Ack: 390, ten: 1460 
Source port: http (80) 
Destination port: 5U288 (50288) 
[stream index: 0] 


Dee É 


Sequence number: 1 (relative sequence number) 
[Next sequence number: 1461 (relative sequence number)] 
Acknowledgement number: 390 (relative ack number) 


Header length: 20 bytes 
® Flay»: 0x10 (ACK) 
window size value: 54 
[calculated window size: 6912] 
[window size scaling factor: 128] 


® Checksum: Oxa90d [validation disabled] 
Q 


[Bytes in flight: 1460] 
+ Hypertext Transfer Protocol 


Observações importantes: 


a Sentido do pacote: servidor -> cliente; 

a Portas de origem e destino: 80 e 50288, respectivamente; 
a SEQ=1 -contador de octetos enviados do servidor; 

a ACK = 390 - contador de octetos recebidos do servidor; 


a Flags: 0x10 (ACK) - indica que o code bit ACK está ligado, porém neste caso não tem signi- 
ficado especial; 


o [SEQ/ACK analysis] [Bytes in flight: 1460] - esta informação fornecida pelo Wireshark 
é apenas a título de orientação; o Wireshark analisa os contadores e informa que este 
segmento está enviando 1460 octetos de dados; 


o [Next sequence number: 1461 (relative sequence number)] - este número é meramente 
informativo, fornecido pelo Wireshark a título de orientação; ele está indicando que o 
próximo SEQ do servidor deverá ser atualizado para 1461, DESDE QUE o cliente reco- 


nheça os dados enviados neste pacote; 


a Observe que na primeira janela onde aparece o pacote número 6, o protocolo indicado é 


o HTTP, o que significa que existem dados da aplicação neste pacote. 


4. O pacote número 7 é semelhante ao número 6, onde também estão sendo enviados 
1460 octetos, totalizando 2920 bytes in flight (2x1460). O pacote número 8 traz algumas 
novidades, conforme mostrado na Figura 8.21. 


No. Time Source Destination Protocol Length Info 








Frame 8: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) 
Ethernet II, Src: HonHaiPr 60:a2:1a (00:24:2c:60:a2:1a), Dst: Cisco-Li_c8:b5:2a (00:18:39:c8:b5:2a) 
Internet Protocol version 4, Src: 192.168.100.103 (192.168.100.103), Dst: 200.147.3.191 (200.147.3.191) 
Transmission Control Protocol, Src Port: 50288 (50288), Dst Port: http (80), Seq: 390, Ack: 2921, Len: 0 
Source port: 50288 (50288) 
Nestination port: http (RO) 
[stream index: 0] 
sequence number: 390 (relative sequence number) 
Acknowledgement number: 2921 (relative ack number) 
Header length: 20 bytes 
Flags: 0x10 (ACK) 
Window size value: 4380 
[calculated window size: 17520] 
[window size scaling factor: 4] 
Checksum: 0x0191 [validation disabled] 
[SEQ/ACK analysis] 
[this is an ACK to the segment in frame: 7] 





Dama 


O E 








Figura 8.21 Observações importantes: 
Pacote número 8 
de dados. a Sentido do pacote: cliente -> servidor; 


o Portas de origem e destino: 50288 e 80, respectivamente; 
a SEQ =390 - contador de octetos enviados do cliente; 

a ACK=2921 - contador de octetos recebidos do cliente; 

o Flags: 0x10 (ACK) - indica que o code bit ACK está ligado; 


o [SEQ/ACK analysis] [This is an ACK to the segment in frame : 7] - esta informação forne- 
cida pelo Wireshark é apenas a título de orientação; o Wireshark analisa os contadores e 
informa que este segmento confirma o recebimento do segmento contido no quadro 7 


recebido anteriormente. 


Observe que este pacote foi enviado pelo TCP, não contém dados da aplicação e faz um reco- 
nhecimento cumulativo dos dados enviados nos pacotes 6 e 7 pelo servidor (reveja o texto 
após a Figura 8.9). Os demais pacotes (até o de número 16) repetem esse mecanismo e não 


trazem nenhuma novidade. 


Fechamento de conexão 


O fechamento de conexão ocorre separadamente em cada direção da conexão. Quando a 
os processos associados a uma conexão não mais desejam enviar dados, qualquer um | 


deles pode solicitar o fechamento da conexdo. 


Internamente, para fechar uma conexão, as entidades TCP adotam o algoritmo ilustrado 


na Figura 8.22. 
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EntidadeA Entidade B 


FIN SEQ=x 


FIN SEQ=x 
ACK=x+1 
ACK=x+1 


FIN SEQ=y ACK=x+1 


FIN SEQ=y ACK=x+1 
ACK=y+1 


Figura 8.22 
Fechamento de 
conexdo TCP. 





Após receber o reconhecimento do último byte de dados transmitido, a entidade que deseja 
fechar a conexão (A) envia um segmento FIN, que possui o bit FIN ligado, indicando um 
pedido de fechamento da conexão. O campo Sequence number deste segmento contém o 


valor do número de sequência (x) do último byte enviado pela entidade nesta conexão. 


Após receber o segmento FIN, a entidade B envia um reconhecimento deste segmento, indi- 
cando o valor x+1 no campo Acknowledgement number. Neste ponto, a conexão está fechada 
na direção da entidade A para a entidade B. 


Na outra direção, a entidade B ainda pode continuar enviando dados. Quando deseja fechar 
a conexão nesta outra direção, a entidade B segue o mesmo procedimento, enviando um 
segmento FIN e recebendo um reconhecimento deste segmento. Observe que o campo 
Acknowledgement number do segmento FIN, enviado pela entidade B, ainda é igual a x+1, 
indicando que nenhum dado foi recebido da entidade A, após o fechamento da conexão 
naquela direção. 


® 
Exercício de fixação 3 _G 
Fechamento de conexdo TCP 


1. Nas atividades anteriores, estudamos a abertura e o envio de dados numa conexão TCP. 
Agora vamos analisar o fechamento da conexão. A Figura 8.23 mostra o pacote número 17 
do fluxo analisado nas atividades anteriores. 


No. Time Source Destination Protocol Length Info 
0. 294557 1 58. O 03 20 1 3.191 CP 54 
— z E - - = m 
= Frame 17: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) 

* Ethernet II, Src: HonHaiPr_60:a2:1a (00:24:2c:60:a2:1a), Dst: Cisco-Li_c8:b5:2a (00:18:39:c8:b5:2a) 

= Internet Protocol version 4, Src: 192.168.100.103 (192.168.100.103), Dst: 200.147.3.191 (200.147.3.191) 

- Transmission Control Protocol, src Port: 50288 (50788), Dst Port: http (RO), Seq: 290, Ack: 11033, ien: 0 
source port: 50288 (50288) 

Destination port: http (80) 

[stream index: U] 

Sequence number: 390 (relative sequence number) 

Acknowledgement number: 11033 (relative ack number) 

Header length: 20 bytes 

Flags: 0x11 (FIN, ACK) 

Wiriduw size value: 4380 

[calculated window size: 17520] 

[window size scaling factor: 4] 

= Checksum: Oxeldf [validation disabled] 


F 





Observações importantes: Figura 8.23 


Pacote número 17. 
a Sentido do pacote: cliente -> servidor; 


o Portas de origem e destino: 50288 e 80, respectivamente; 
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o SEQ = 390 - contador de octetos enviados do cliente; 
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a ACK = 11033 - contador de octetos recebidos do cliente; 


o Flags: 0x11 (FIN, ACK) - indica que os code bits FIN, ACK estão ligados; portanto, o cliente 
está solicitando o fechamento da conexão no sentido cliente -> servidor. 


Este pacote foi enviado pelo protocolo TCP e não carrega dados da aplicação. 


2. Analisemos o pacote 18 deste mesmo fluxo, mostrado na Figura 8.24. 


No. Time Source Destination Protocol Length Info 
z 48 47.3 02 : A 54 








4 m 





= Frame 18: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) 

® Ethernet II, Sec: Cistu-Li c8:b5:24 (00:18:39:08:b5:24), Dsl: HurHaiPr_60:a2:1la (00:24:20 :60:42:1a) 

E Internet Protocol version 4, Src: 200. 147.3.1901 (200.147.3. 191), Dst: 192.168.100.103 (192.168.100.103) 
& Transmission Control Protocol, Src Port: http (80), Dst Port: 50288 (50288), Seq: 11033, Ack: 391, Len: O 
Source port: http (80) 

Destination port: 50288 (50288) 

[stream index: 0] 

Sequence number: 11033 (relative sequence number) 

Acknowledgement number: 391 (relative ack number) 

Header length: 20 bytes 

Flags: 0x10 (ACK) 

window size value: 54 

[Calculated window size: 6912] 

[window size scaling factor: 128] 

checksum: Oxf2c5 [validation disabled] 

= [SEQ/ack analysis] 

[This is an ACK to the segment in frame: 17] 


E 


E] 








Figura 8.24 Observações importantes: 
Pacote número 18. 
a Sentido do pacote: servidor -> cliente; 


o Portas de origem e destino: 80 e 50288, respectivamente; 
a SEQ = 11033 - contador de octetos enviados do servidor; 
a ACK = 391 - contador de octetos recebidos do servidor; 

o Flags: 0x10 (ACK) - indica que o code bit ACK está ligado; 


o [SEQ/ACK analysis] [This is an ACK to the segment in frame : 17] - esta informação forne- 
cida pelo Wireshark é apenas a título de orientação; o Wireshark analisa os contadores e 
informa que este segmento confirma o recebimento do segmento contido no quadro 17 
recebido anteriormente. 


No pacote 17 (Figura 8.23), o cliente informa que o seu contador de octetos enviados é 
SEQ=390, e o referido pacote não enviou dados da aplicação. Por que o contador de rece- 


bidos do servidor no pacote 18 indica: ACK=391? 
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A Figura 8.25 mostra um resumo do fluxo de pacotes aqui analisado. 


Numero 


10 
11 
12 
13 
14 


15 


16 


17 


18 


Sentido 


CLI -> SER 


SER -> CLI 


CLI -> SER 
CLI -> SER 
SER -> CLI 
SER -> CLI 
SER -> CLI 
CLI -> SER 
SER -> CLI 
SER -> CLI 
CLI -> SER 
SER -> CLI 
SER -> CLI 
SER -> CLI 


SER -> CLI 


CLI -> SER 


CLI -> SER 


SER -> CLI 


Octetos 
Dados 


389 


1460 


1460 


1460 


1460 


1460 
1460 
1460 


811 


Flags 


SYN 


SYN,ACK 


ACK 
PSH,ACK 
ACK 
ACK 
ACK 
ACK 
ACK 
ACK 
ACK 
ACK 
ACK 
ACK 


FIN,PSH,ACK 


ACK 


FIN,ACK 


ACK 


Contadores 
SEQ ACK 
0 = 

0 1 

fl 1 

1| 1 

1 390 

1 390 
1461 390 
390 2921 
2921 390 
4381 390 
390 5841 
5841 390 
7301 390 
8761 390 
10221 390 
390 11033 
390 11033 
11033 391 


Observações 


Solicita estabelecimento de conexão; 
inicializa contador SEQ. 


Solicita estabelecimento de conexão; 
inicializa contador SEQ; aceita pedido 
de conexão. 

Aceita pedido de conexão. 

Envia 389 octetos. 

Reconhece o envio de dados. 

Envia 1460 octetos. 

Envia 1460 octetos. 

Reconhece o envio de dados. 

Envia 1460 octetos. 

Envia 1460 octetos. 

Reconhece o envio de dados. 

Envia 1460 octetos. 

Envia 1460 octetos. 

Envia 1460 octetos. 


Envia 811 octetos; solicita fecha- 
mento de conexão. 


Reconhece o envio de dados; aceita 
fechamento de conexão. 


Solicita fechamento de conexão. 


Aceita fechamento de conexão. 


Em resumo, os pacotes 1 a 3 executam a abertura da conexão TCP, os pacotes 4 a 15 executam Figura 8.25 


o envio dos dados da aplicação e os pacotes 15 a 18 fecham a conexão TCP. 


Resumo do fluxo 
de pacotes. 


Os dados enviados pelo servidor para o cliente foram na quantidade de 1460 bytes em cada 


pacote, exceto no último, de 811 bytes. Por quê? 
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EZ Roteiro de Atividades 8 


Figura 8.26 
Exemplo de uso do 
comando netstat. 


Atividade 8.1- Portas TCP e UDP 


Uma determinada aplicação utiliza a porta TCP 500, enquanto outra aplicação utiliza a porta 
UDP 500. Dado que ambas as aplicações estão sendo executadas na mesma estação, como 
o sistema operacional é capaz de diferenciar os dados que devem ser repassados para cada 


uma destas portas? 








Atividade 8.2 - Campo com tamanho do cabeçalho 


Avaliando os formatos dos datagramas UDP e segmentos TCP, podemos perceber que o TCP 
adota um campo que indica o tamanho do cabeçalho. Por que o protocolo UDP não adota 


um campo com a mesma funcionalidade? 








Atividade 8.3 — Portas, conexões e endpoints 


Diferentemente do protocolo UDP, que usa apenas a porta de destino para demultiplexar os 
datagramas recebidos, o protocolo TCP utiliza a identificação da conexão, ou seja, um par de 


endpoints. Por que o TCP não pode utilizar apenas a porta de destino? 








Atividade 8.4 — Portas UDP 


> netstat -uan 


Proto Recv-Q Send-Q Local Address Foreign Address State 


udp 0 0 0-0.0:0:5000 AO MORO 
udp 0 O 00.0.0:10000 00-0037 
udp 0 0 000-015000 00 00:5 


Em sistemas Linux, o comando netstat, ativado com a opção -u, permite a visualização das 
portas UDP em uso. A Figura 8.26 mostra um exemplo de uso do comando netstat. A opção -a 
sinaliza que todas as portas UDP ativas devem ser listadas. A opção -n indica que os ende- 


reços IP e as portas não devem ser traduzidos para os respectivos nomes. 


Para cada porta, o comando netstat mostra: o protocolo adotado (Proto); o número de bytes 
na fila de recepção (Recv-Q); o número de bytes na fila de transmissão (Send-Q); o endereço 
IP e a porta UDP local (Local Address); o endereço IP e a porta UDP remota (Foreign Address). 
O endereço IP local 0.0.0.0 indica que os datagramas UDP serão aceitos quando encapsu- 
lados em datagramas IP que são endereçados a qualquer endereço IP da estação. Por outro 
lado, o endereço IP remoto 0.0.0.0 indica que os datagramas UDP serão aceitos de qualquer 


endereço IP remoto. 
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1. Execute o comando netstat e identifique as portas UDP ativas na sua estação. Em esta- 
ções Windows, o comando deve ser c:\netstat -p UDP -an. 











2. No Linux, o arquivo /etc/services descreve a associação de portas TCP e UDP com os 
nomes dos respectivos serviços. No Windows, o arquivo services está localizado em 
“C:\Windows\System32\drivers\etc”. Identifique os nomes dos serviços UDP que estão 
ativos na sua estação. 











Atividade 8.5 — Portas TCP 


O comando netstat, ativado com a opção -t, permite identificar as conexões TCP ativas, como 
também as portas TCP que estão aguardando requisições de conexão. A Figura 8.27 mostra 
outro exemplo de uso do comando netstat. A opção -a sinaliza que todas as conexões e 
portas TCP devem ser listadas. A opção -n indica que os endereços IP e as portas não devem 


ser traduzidos para os respectivos nomes. 


> netstat -tan 








Proto Recv-Q Send-Q Local Address Foreign Address State 
tcp 0 0 0.0.0.0:7 0.0.0.0:* LISTEN 
tcp 0 0 0.0.0.0:9 0.0.0.0:* LISTEN 
tcp 0 0 0.0.0.0:13 0.0.0.0:* LISTEN 
Figura 8.27 
tcp 0 0 192.168.1.2:9 192.168.1.1:32000 ESTABLISHED Exemplo de uso do 


comando netstat. 
Para cada conexão, o comando netstat mostra: o protocolo adotado (Proto); o número de 
bytes no buffer de recepção (Recv-Q); o número de bytes no buffer de transmissão (Send-Q); 
o endpoint local (Local Address); o endpoint remoto (Foreign Address); e o estado da conexão. 
As portas que aguardam requisições de conexão possuem o estado LISTEN (mostrado 
apenas com a opção -a). Já as conexões ativas possuem o estado ESTABLISHED. No estado 
LISTEN, o endereço IP local 0.0.0.0 indica que as requisições de conexão serão aceitas 
quando encapsuladas em datagramas IP que são endereçados a qualquer endereço IP da 
estação. Por outro lado, o endereço IP remoto 0.0.0.0 indica que as requisições de conexão 


serão aceitas de qualquer endereço IP remoto. 


1. Execute o comando netstat e identifique as conexões TCP ativas e as portas TCP que 
estão aguardando requisições de conexão. Em estações Windows, o comando deve ser 
c:\netstat -p TCP -an. 








2. Identifique os nomes dos serviços TCP que estão ativos e aguardando conexões. 








Camada de aplicação 











Descrever as principais funções providas pela interface socket para implementar 
os diversos clientes e servidores. Apresentar considerações sobre o projeto de 





objetivos 


servidores, identificando e discutindo os diferentes modelos de implementação. 







Camada de aplicação, com o detalhamento do uso do modelo cliente-servidor para o 





desenvolvimento de aplicações em uma rede TCP/IP. 


S0}199U09 







Fundamentos e protocolos da camada de aplicação 


o Trata os detalhes específicos de cada tipo de aplicação. 
m Mensagens trocadas por cada tipo de aplicação definem um protocolo de aplicação. 
m Cada protocolo de aplicação especifica a sintaxe e a semântica de suas mensagens. 
a Existem diversos protocolos de aplicação: 
m FTP 
m SMTP 
m DNS 
a HTTP 
oa Implementada via processos de aplicação. 
a Processos interagem usando o modelo cliente-servidor. 
a Processos usam os serviços da camada de transporte. 


a Processos interagem com as implementações dos protocolos de transporte, através 
de uma API. 


ao Ainterface socket é um dos principais exemplos de interface de interação. 





Até aqui, estudamos detalhes da arquitetura TCP/IP, incluindo os protocolos que proveem 
os serviços de comunicação fim-a-fim e a função de roteamento de datagramas. Neste 
capítulo, vamos estudar a camada de aplicação, que na arquitetura TCP/IP trata dos detalhes 


específicos de cada tipo de aplicação. 


O conjunto de mensagens trocadas por cada tipo de aplicação define um protocolo de apli- 


cação. Cada protocolo de aplicação especifica a sintaxe e a semântica de suas mensagens. 
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Existem vários protocolos de aplicação, como: FTP (File Transfer Protocol), SMTP (Simple Mail 
Transfer Protocol), DNS (Domain Name System) e HTTP (Hypertext Transfer Protocol). 
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Ao contrário das demais camadas (transporte, rede e interface de rede), que são direta- 
mente implementadas no núcleo (kernel) do sistema operacional, a camada de aplicação é 
implementada através de processos, que são representações do sistema operacional para 
programas em execução. Ou seja, na arquitetura TCP/IP, uma aplicação é apenas um pro- 
grama em execução (processo). 


Na camada de aplicação, os usuários executam programas de aplicação que acessam serviços 
disponíveis através de uma inter-rede TCP/IP. Na arquitetura TCP/IP, os programas de apli- 


cação interagem adotando o padrão de interação denominado modelo cliente-servidor. 


aplicações se comuniquem. Uma aplicação interage com um dos protocolos de transporte 
para enviar e receber dados. Cada aplicação escolhe o serviço de transporte requerido. Se 
a aplicação adota o protocolo TCP, suas mensagens são encapsuladas em segmentos TCP, 
compondo um fluxo contínuo de dados. Caso contrário, se a aplicação adota o protocolo 
UDP, suas mensagens são encapsuladas em datagramas UDP, compondo uma sequência de 
mensagens individuais. 


Para selecionar e usar os serviços da camada de transporte, os processos de aplicação inte- 
ragem com as implementações dos protocolos de transporte no sistema operacional através 
de uma API (Application Programming Interface), provida pelo próprio sistema operacional. 


A interface socket é um dos principais exemplos de interface de interação. 


Neste capítulo, estudaremos a camada de aplicação examinando o modelo cliente-servidor, 
a interface socket, os modelos de implementação de servidores e os principais serviços e 
protocolos de aplicação. 


Modelo cliente-servidor 


Componentes: 
o Servidor 


m Processo que oferece um serviço que pode ser requisitado pelos clientes através 
da rede. 


m Comunica-se com o cliente somente após receber requisição. 
m Executa continuamente. 

o Cliente 
m Processo que requisita um serviço oferecido por um servidor. 
a Inicia a interação com o servidor. 
m Disponibiliza a interface para o usuário. 
m Finaliza a execução após ser utilizado pelo usuário. 


No modelo cliente-servidor, um servidor é um processo de aplicação que oferece um serviço que 
pode ser requisitado pelos clientes através da rede. Um servidor aceita requisições dos clientes, 


executa o processamento das requisições, e retorna os resultados para os respectivos clientes. 


Um cliente é um processo de aplicação que requisita um serviço oferecido por um servidor. 
Um cliente envia requisições através da rede para um ou mesmo para vários servidores, e, 


em seguida, aguarda o recebimento das respectivas respostas. 





Modelo 
cliente-servidor 


Modelo de interação em 
um sistema distribuído 
no qual o processo 
servidor oferece um 
serviço requisitado pelo 
processo cliente. 


Provê a comunicação 
fim-a-fim entre 
aplicações. 


Paradigma requisição-resposta 


a Servidor 
m Aceita requisições dos clientes. 
m Executa o processamento das requisições. 
a Retorna os resultados para os clientes. 
o Cliente 
m Envia requisições através da rede para um ou vários servidores. 


m Aguarda o recebimento das respostas. 


A interação entre cliente e servidor adota o paradigma requisição-resposta, onde o cliente 
envia uma requisição e aguarda a resposta do servidor. Observe que o cliente é responsável 
por iniciar a interação com o servidor. O servidor somente se comunica com o cliente após 
receber uma requisição. 


É importante ressaltar que, geralmente, um cliente disponibiliza a interface para o usuário e 
somente existe enquanto está sendo utilizado pelo usuário. Desta forma, o cliente sempre 
finaliza sua execução após enviar um número finito de requisições a um ou vários servi- 
dores. Por outro lado, o servidor executa continuamente, enquanto o sistema está opera- 


cional, aceitando requisições e enviando respostas. 


Por exemplo, quando o usuário utiliza um navegador (cliente) para acessar recursos disponibili- 
zados por servidores web, o navegador envia requisições para estes servidores para recuperar 
os recursos desejados. Quando não deseja mais utilizar o navegador, o usuário simplesmente 
finaliza a sua execução. No entanto, após o término da execução do navegador, os servidores 


que foram acessados continuam executando, atendendo a requisições de outros clientes. 


Para desenvolver uma aplicação cliente-servidor, uma das primeiras decisões que o projetista 
deve tomar diz respeito ao protocolo de transporte a ser adotado. A interação cliente-servidor 
pode ser realizada usando o serviço de datagramas ou o serviço de circuito virtual da camada 
de transporte. Ou seja, os protocolos UDP e TCP podem ser utilizados para transportar men- 


sagens do cliente para o servidor e vice-versa. 


O protocolo UDP fornece um serviço não confiável e baseado em datagramas, que não garante 
a entrega e a sequência dos datagramas. Diferentemente, o protocolo TCP fornece um serviço 


confiável e baseado em fluxo de dados, que garante a entrega e a sequência do fluxo de dados. 


Identificação de clientes e servidores 


a Clientes e servidores são identificados por meio de portas. a 


o Cliente deve conhecer, previamente, a porta usada pelo servidor. 

a Servidor não precisa conhecer, previamente, a porta usada pelo cliente. 

a Servidor descobre a porta usada pelo cliente somente após receber a requisição. 

a Portas são permanentemente reservadas para serviços padronizados e bem conhecidos. 
a Porta 53 (DNS) 
m Porta 161 (SNMP) 


o Portas reservadas são utilizadas pelos servidores que implementam os 


respectivos serviços. 


a Demais portas são disponíveis para os clientes. 
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Vimos que a arquitetura TCP/IP adota o conceito de porta para identificar os processos Porta 


comunicantes. Portanto, no modelo cliente-servidor, o cliente e o servidor devem identificar-se Representação interna 


usando determinados números de portas. do sistema operacional 
de um ponto de comu- 


Lembre-se de que o cliente é sempre responsável por iniciar a interação com o servidor. nica gao para EnyVIoE 
, . g ) recebimento de dados. 
Para tal, o cliente deve, previamente, conhecer o número da porta usada pelo servidor. Por 
outro lado, o servidor somente se comunica com o cliente após receber uma requisição 
dele. O servidor descobre o número da porta usada pelo cliente somente após receber a 
requisição. Logo, o servidor não precisa, previamente, conhecer a porta usada pelo cliente. 
Consequentemente, no modelo cliente-servidor, somente a porta usada pelo servidor deve 


ser previamente conhecida pelo cliente. 


Em função disso, na arquitetura TCP/IP, algumas portas são permanentemente atribuídas ou 
reservadas para serviços padronizados e conhecidos (well known services). Por exemplo, as 
portas 53 e 161 são reservadas para DNS e SNMP, respectivamente. As portas reservadas são 
utilizadas pelos servidores que oferecem estes serviços bem conhecidos. Diferentemente, 

as demais portas são disponíveis para uso pelos clientes. Em sistemas Unix, os números das 


portas reservadas e os nomes dos respectivos serviços são indicados no arquivo /etc/services. 


A atribuição de uma porta única a cada serviço simplifica o desenvolvimento de clientes 
e servidores, pois nenhum serviço adicional é requerido para que o cliente descubra o 


número da porta utilizada pelo servidor que oferece o serviço desejado. 


Negociação de portas 





a Servidor requisita uma porta reservada e conhecida, previamente reservada ao 
seu serviço. 


m Servidor informa ao sistema operacional a porta que quer utilizar. 
a Cliente requisita uma porta qualquer não reservada. 
m Sistema operacional escolhe a porta arbitrária do cliente. 


O processo servidor negocia com o sistema operacional a possibilidade de abrir e usar uma 
porta conhecida, previamente reservada para o serviço oferecido pelo servidor. Geralmente, 
o processo servidor informa ao sistema operacional o número da porta que deseja utilizar. 
Após obter a permissão de utilizar a porta, o processo servidor aguarda, passivamente, 
requisições naquela porta. Após receber uma requisição, o servidor trata a requisição, 


retorna a resposta para o cliente, e volta a aguardar novas requisições. 


No outro lado, o processo cliente negocia com o sistema operacional a possibilidade de abrir 
e usar uma porta qualquer não reservada. Geralmente, a escolha do número da porta usada 
pelo cliente é realizada pelo próprio sistema operacional. Após obter a permissão de utilizar 
uma porta, o processo cliente envia uma requisição ao servidor através daquela porta, e, 
então, aguarda a resposta do servidor. Observe que o cliente não usa portas conhecidas, 
mas qualquer porta atribuída pelo sistema operacional. 


Lembre-se de que, dependendo do serviço de transporte adotado na interação cliente-servidor, 
as mensagens de requisição e resposta são transportadas em datagramas UDP ou seg- 
mentos TCP, que, como já sabemos, possuem campos que identificam as portas de origem 

e destino. Nas requisições, as portas de origem e destino identificam o cliente e o servidor, 
respectivamente. Já nas respostas, as portas origem e destino identificam o servidor e o 
cliente, respectivamente. 


O sistema operacional deve assegurar que, quando um processo solicita a criação de uma 
determinada porta, somente este processo estará associado àquela porta. Vale ressaltar 
que, em sistemas Unix, um processo (pai) pode criar outros processos (filhos), que também 
estarão associados à mesma porta do processo pai. Portanto, é comum encontrar situações 
onde vários processos (pai e filhos) estão simultaneamente associados a uma mesma porta. 
Nestes casos, o projetista da aplicação é responsável por definir e controlar o acesso à porta 
usada conjuntamente pelos vários processos. Além disso, um determinado processo pode 


requisitar diversas portas ao sistema operacional. 


Atribuição de portas 
o Reservada (0 - 1.023) 


a Atribuídas a serviços padronizados. 
m Acessadas apenas por processos privilegiados. 
o Registradas (1.024 - 49.151) 


m Não são reservadas, mas apenas listadas para coordenar o uso para serviços 


não padronizados. 
m Acessadas por quaisquer processos. 
a Dinâmicas (49.152 - 65.535) 


m Não possuem reserva, podendo ser usadas pelos clientes. 





m Acessadas por quaisquer processos. 


A atribuição dos números de portas é realizada pela IANA (Internet Assigned Numbers 
Authority), autoridade responsável pela atribuição dos números de portas reservadas 


e registradas. 


Os números das portas são divididos em três faixas: portas reservadas ou conhecidas (0 até 
1.023); portas registradas (1.024 até 49.151); e portas dinâmicas (49.152 até 65.535). A lista 
completa de portas reservadas e registradas pode ser encontrada no catálogo de portas 


mantido pela IANA. 


As portas reservadas são atribuídas pela IANA aos serviços mais utilizados. Em muitos 

. = sistemas, as portas reservadas somente podem ser manipuladas por processos do sistema 
Para identificar as 
portas reservadas e 
registradas, consulte: listadas pela IANA para coordenar o uso delas pela comunidade para serviços não padroni- 


ou por alguns processos privilegiados. As portas registradas não são atribuídas, mas apenas 


http://www.iana.org/ 


zados. As portas dinâmicas não possuem qualquer tipo de reserva e, na maioria dos casos, 
são usadas apenas pelos clientes. Em muitos sistemas, as portas registradas e dinâmicas 


podem ser acessadas por qualquer processo não privilegiado. 





Interface socket 


o Socket zal 


m Representação interna do sistema operacional para um ponto de comunicação. 
o Interface socket 


m Define a interface entre os processos de aplicação e as implementações dos ser- 


viços de transporte. 


a Originalmente proposta para sistemas Unix e linguagem C. 





= Amplamente adotada em diversas plataformas e linguagens. 
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m Um socket é um ponto de comunicação: 
a Identificado pelos endpoints local e remoto. 


m Cada endpoint é representado pelo par (endereço IP, porta). 


A arquitetura TCP/IP especifica o conjunto de protocolos, mas não define a interface de 
interação entre os processos de aplicação e implementação dos protocolos no sistema ope- 
racional. Portanto, a interface de interação está fora do escopo das especificações da família 
de protocolos TCP/IP. Apesar da falta de padronização, avaliar um exemplo de interface de 
interação auxilia o entendimento do uso da arquitetura TCP/IP e do modelo cliente-servidor. 


A interface socket é apenas um exemplo de interface de interação entre os processos de 
aplicação e implementação dos protocolos da arquitetura TCP/IP. Originalmente, a inter- 


face socket foi proposta para sistemas Unix e linguagem C. No entanto, esta interface Linguagem C 


tem sido amplamente adotada em diversas plataformas e linguagens de programação. Linguagem de progra- 
mação procedural 
utilizada para desen- 
volver as diversas 
através dos protocolos UDP e TCP. famílias do sistema 
operacional Unix. 


Por exemplo, a interface Winsocket é adotada em sistemas Windows. Em Java, as classes 


Socket, DatagramSocket e ServerSocket são oferecidas para permitir a comunicação 


Neste capítulo, a título de exemplificação, adotaremos a interface socket proposta para sis- 
temas Unix e linguagem C. É importante ressaltar que o estudo da interface socket tem por 
objetivo apenas identificar as funcionalidades, não tratando de detalhes de uso das várias 
funções. Assim, os parâmetros de entrada e saída de cada uma das funções mencionadas 
não serão discutidos em detalhes, mas apenas citados. 


Antes de estudar as funções suportadas pela interface socket, vamos, primeiramente, 
entender como o sistema operacional identifica e gerencia os diversos sockets. 


Estados de um socket 


\ 


a Socket ativo 
m Usado pelo cliente para enviar ativamente requisições de conexão ao servidor. 
a Socket passivo 


m Usado pelo servidor para aguardar passivamente por requisições de conexão. 


=p cossa Jump established 





Figura 9.1 
Estados de um 
socket ativo. 


Para os processos cliente e servidor, um socket representa apenas um ponto de comu- 


nicação. Internamente, o sistema operacional identifica o socket pelos endpoints local e Endpoint 

remoto, cada um deles representado pelo par (endereço IP, porta). Identifica de forma 
individual e única um 

Considerando a interação cliente-servidor, um processo servidor deve abrir um socket e ponto de comunicação 

ficar passivamente aguardando requisições dos clientes. Já o processo cliente deve abrirum €™M toda a inter-rede, 


sendo representado 
pelo endereço IP da 
abre o socket no modo passivo, enquanto o cliente abre o socket no modo ativo. estação e a porta 
associada ao respectivo 
processo de aplicação. 


socket e ativamente utilizá-lo, enviando uma requisição ao servidor. Diz-se que o servidor 


Figura 9.2 
Estados de um 
socket passivo. 


Socket UDP 


Socket que utiliza o pro- 
tocolo UDP como meca- } 
nismo de transporte. į 


Socket TCP à 


Socket que utiliza o pro- 
tocolo TCP como meca- 
nismo de transporte. 








Socket ativo 


Socket utilizado 
pelo cliente para esta- 


belecer uma conexão ..... 


com um servidor. 


Socket passivo 


Socket utilizado pelo 
servidor para aguardar 


requisições dos clientes. 





established 





Internamente, o sistema operacional identifica e gerencia a interação entre o cliente e o ser- 
vidor usando o respectivo socket, que, por sua vez, identifica seus endpoints local e remoto. 


No entanto, sockets UDP e TCP são gerenciados de forma diferente. 


a O protocolo UDP não adota o conceito de conexão. Assim, exceto quando a fila de 
transmissão e recepção da respectiva porta está cheia, um socket UDP está sempre 
pronto para enviar e receber dados. Ou seja, a qualquer momento, o processo local pode 
escrever ou receber dados. Desta forma, o sistema operacional não precisa definir dife- 


rentes estados para sockets UDP. 


ao Jao protocolo TCP é orientado à conexão. Cada conexão é identificada de forma única 


pelo par de endpoints associado ao socket. Ao contrário de um socket UDP, que está 


belecer uma conexão com a outra extremidade. Após estabelecer a conexão, o processo 
local pode enviar e receber dados usando o socket TCP. Por fim, a conexão deve ser 


fechada, liberando o socket. 


Para sinalizar a situação atual da conexão, um socket TCP passa por vários estados, onde 
os principais são: listen, established e closed. Todo socket TCP encontra-se inicialmente no 
estado closed. Vale ressaltar que existem estados intermediários que não foram mencio- 


nados, para simplificar o entendimento. 


A figura 9.1 ilustra os estados de um socket TCP manipulado pelo cliente. Lembre-se de que 


o cliente cria o socket no modo ativo. Neste caso, após a criação e configuração, o cliente 


imediatamente envia uma requisição de conexão para o servidor. Após o estabelecimento 
da conexão, o socket do cliente passa do estado closed para o estado established. Por fim, 


quando a conexão é fechada, o socket volta ao estado closed. 


No outro lado, o servidor cria o socket no modo passivo. A figura 9.2 ilustra os estados de 


um socket manipulado pelo servidor. Neste caso, após a criação e configuração, o socket 
do servidor passa do estado closed para o estado listen, indicando que está passivamente 
aguardando por requisições de conexão. No estado listen, o servidor pode decidir fechar 

o socket por um motivo qualquer, levando-o ao estado closed. No entanto, na operação 
normal do servidor, após receber e aceitar uma requisição de conexão, o socket passa do 
estado listen para o estado established. Por fim, quando a conexão é fechada, o socket volta 


ao estado closed. 


Tratamento de endpoints 


a Endpoint local 


a Endpoint remoto | 


Como já sabemos, internamente o sistema operacional identifica o socket pelos endpoints local 
e remoto, cada um deles representado pelo par (endereço IP, porta). O sistema operacional 
adota um procedimento default para atribuir valores aos endpoints local e remoto, mas a inter- 
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Endpoint local 


a 
Criado, por default, com o endereço IP especial 0.0.0.0 e uma porta arbitrária, selecionada 
pelo sistema operacional. Pode ser atribuído um endereço IP e uma porta específica. 


o Endereço IP específico deve ser evitado em sistemas multihomed, exceto por questões 
de segurança. 


mn Servidor deve configurar uma porta específica. 


a Cliente usa a porta selecionada pelo sistema operacional. 


Por default, o endpoint local de um socket UDP ou TCP é identificado com o endereço IP 
especial 0.0.0.0 e uma porta qualquer disponível, selecionada pelo próprio sistema opera- 
cional. O endereço 0.0.0.0 indica que datagramas UDP ou requisições de conexão TCP são 
aceitos quando transportados em datagramas IP destinados a qualquer endereço IP das 


interfaces de rede do sistema. 


No entanto, o processo que está manipulando o socket UDP ou TCP pode especificar o ende- 
reço IP e a porta do endpoint local. Quando um endpoint local possui um endereço IP espe- 
cífico, os datagramas UDP ou segmentos TCP (destinados à sua porta) somente são aceitos 
quando endereçados àquele endereço IP. O servidor deve configurar uma porta específica e 


o cliente deve utilizar a porta selecionada pelo sistema operacional. 


Observe que, no caso de roteadores e estações multihomed, que possuem múltiplos ende- 
reços IP, a associação de um endereço IP específico ao endpoint local força que datagramas 
UDP ou segmentos TCP somente possam ser aceitos quando destinados àquele endereço IP. 
Desta forma, exceto por questões de segurança, geralmente deve-se evitar a associação de 
um endereço IP específico ao endpoint local. 


Endpoint remoto 


a 
Criado, por default, com o endereço IP especial 0.0.0.0 e a porta “*”. Pode ser atribuído 
um endereço IP e uma porta específica. 


o Cliente UDP ou TCP deve especificar o endereço IP e a porta do servidor. 


a Servidor UDP pode configurar um endereço IP e uma porta específica, devendo ser 


evitado em sistemas multihomed (exceto por questão de segurança). 


a Servidor TCP usa a associação default. 


Como mencionado, o sistema operacional também gerencia o endereço IP e a porta asso- 
ciada ao endpoint remoto de um socket. Por default, na criação de um socket UDP ou TCP, 
internamente, o sistema operacional associa o endereço IP especial 0.0.0.0 e a porta “*” ao 
endpoint remoto, indicando, no servidor, que datagramas UDP ou requisições de conexão 


TCP são aceitos quando enviados de qualquer endereço IP e porta remota. 


A interface socket também provê mecanismos que permitem especificar o endereço IP e a 
porta do endpoint remoto. Antes de interagir com um servidor, o cliente UDP ou TCP deve 
associar o endereço IP e a porta do servidor ao endpoint remoto do seu socket. O servidor 
UDP pode atribuir um endereço IP e uma porta ao seu endpoint remoto. Neste caso, apenas 
os datagramas UDP enviados a partir daquele endereço IP e porta são aceitos. Novamente, 
exceto por questões de segurança, comumente, deve-se evitar a associação de um endereço 


Figura 9.3 
Endpoints local 
e remoto. 


IP e uma porta específica ao endpoint remoto do socket de um servidor UDP. Em geral, a 
interface socket não permite ao servidor TCP explicitamente associar um endereço IP e uma 
porta ao endpoint remoto de seu socket passivo. Portanto, os sockets passivos de servi- 


dores TCP usam a associação default. 
Endpoints local e remoto 


CJ 
Varios sockets podem utilizar o mesmo número de porta local, desde que seus respec- 


tivos endpoints local e remoto sejam diferentes. 


> netstat -uan 


Proto Recv-Q Send-Q Local Address Foreign Address State 
udp 0 0 192 GS a GIGA ORORORO Res 
udp 0 0 192.168.1.65:161 0.00.03" 
udp 0 0 0.0.0.0:161 ORO ROR Ores 


> netstat -tan 


Proto Recv-Q Send-Q Local Address Foreign Address State 
tcp 0 0 192.166. 05:25 0.0.0025 LISTEN 
tcp 0 0 IQ2Z MGS 1 M9325 00.0.03% LISTEN 
tcp 0 0 0.0.0.0:25 ORO ROR LISTEN 








É possível que varios sockets utilizem o mesmo número de porta local UDP ou TCP, desde 
que seus respectivos endpoints local e remoto possuam valores distintos. Por exemplo, o 
primeiro quadro da figura 9.3 mostra três sockets UDP que utilizam a porta 161. Os dois 
primeiros somente aceitam datagramas UDP destinados aos endereços IP: 192.168.1.33 e 
192.168.1.65. Por outro lado, datagramas UDP destinados a quaisquer outros endereços IP 
locais, diferentes de 192.168.1.33 e 192.168.1.65, serão repassados ao terceiro socket, que 
possui o endereço especial 0.0.0.0 associado ao endpoint local. Portanto, na demultiple- 


xação, o endpoint local que possui o endereço especial 0.0.0.0 deve ser avaliado por último. 


O mesmo comportamento também se aplica a sockets TCP. Por exemplo, o segundo quadro 
da mesma figura 9.3 mostra um exemplo de três sockets TCP que utilizam a porta 25. 

Os dois primeiros somente aceitam requisições de conexão TCP destinadas ao endereço IP: 
192.168.1.65 e 192.168.1.129. Por outro lado, requisições de conexão destinadas a quaisquer 
outros endereços IP locais, diferentes de 192.168.1.65 e 192.168.1.129, serão repassadas ao 


terceiro socket, que possui o endereço especial 0.0.0.0 associado ao endpoint local. 


Implementação 


Modelo de programação: 

o Explora chamadas ao sistema operacional. 

a Adota o modelo de arquivo baseado no paradigma “abrir-ler-escrever-fechar”. 

Nos sistemas Unix, a interface socket explora o conceito de chamada ao sistema operacional 
(system call), cuja ativação é semelhante à chamada de procedimento em linguagens de pro- 


gramação, onde argumentos são passados e resultados são retornados. A interface socket 
utiliza um modelo de programação bastante semelhante ao modelo adotado para mani- 
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pular arquivos, baseado no paradigma “abrir-ler-escrever-fechar”, mecanismo utilizado pelos 
processos para ativar facilidades providas pelo núcleo (kernel) do sistema operacional. 


Neste modelo, inicialmente, o processo realiza uma chamada ao sistema operacional para 
criar e obter a permissão de uso de um determinado socket. Em seguida, após configurar 
algumas características deste socket, o processo pode ler e escrever dados neste socket. Por 
fim, o processo realiza uma chamada ao sistema operacional para fechar o socket, indicando 


que não mais deseja utilizá-lo. 


Para permitir o uso da interface socket, os sistemas Unix proveem um conjunto de funções 


na linguagem C. As principais funções usadas pelos processos cliente e servidor são: 

o Socket- cria novo socket. 

ao Bind - associa endereço IP e porta ao endpoint local do socket. 

a Listen -indica que socket está pronto para receber conexão. 

ao Accept - bloqueia processo até chegada de conexão. 

a Connect - estabelece conexão com endpoint remoto. 

o Read/Recvfrom - lê dados de um socket TCP/socket UDP. 

a Write/Sendto - envia dados pelo socket TCP/socket UDP. 

Embora os processos cliente e servidor adotem a mesma interface socket, existem algumas 
diferenças na forma e tipo das funções utilizadas. Algumas destas funções são utilizadas 
tanto pelo cliente quanto pelo servidor. Por exemplo, a função socket é usada por ambos os 
processos para criar um novo socket. No entanto, existem funções exclusivamente utili- 


zadas pelo cliente ou pelo servidor. Por exemplo, somente o processo cliente utiliza a função 
connect, enquanto apenas o processo servidor utiliza a função accept. 


Além disso, dependendo do protocolo de transporte adotado pelo socket, algumas destas 
funções não são utilizadas ou podem ser opcionalmente utilizadas. Por exemplo, as funções 
connect e accept não precisam ser utilizadas em sockets UDP, enquanto são essenciais em 
sockets TCP. Consequentemente, embora a interface socket suporte ambos os protocolos de 
transporte, existem diferenças na implementação de clientes e servidores UDP e TCP. 


Considerando as diferentes possibilidades de uso das funções providas na interface socket, 
a seguir vamos discutir os modelos clássicos de implementação de clientes e servidores que 


adotam os protocolos UDP e TCP. 


Clientes e servidores UDP 


a Baseados em datagramas. 

a Mapeados sobre o protocolo UDP. 

a Bind associa a porta específica ao endpoint local. 
a Endereço 0.0.0.0 reservado ao endpoint local. 

mn Recvfrom processa as mensagens recebidas. 


a O servidor envia uma resposta com sendto. 


Servidor UDP 


Comunicação 


Cliente UDP 


Figura 9.4 
Modelo de imple- 
mentação de 
clientes e servi- 
dores UDP. 





A figura 9.4 mostra o modelo clássico de implementação de clientes e servidores UDP. 
Inicialmente, o cliente e o servidor criam e obtêm a permissão de uso de seus respectivos 
sockets usando a função socket. Como parâmetro desta função, os processos cliente e 
servidor informam que o socket deve adotar o serviço de transporte baseado em data- 
gramas. Internamente, o sistema operacional mapeia este serviço para o protocolo UDP. 
Como resultado, a função socket retorna o descritor do socket, que o identifica interna- 


mente no sistema operacional. 


Lembre-se de que o servidor adota uma porta reservada e conhecida. No entanto, a função socket 
não define o número da porta associada ao endpoint local do socket criado. Para tal, o servidor 
deve usar a função bind, informando o endereço IP e o número da porta específica que devem ser 
associados ao endpoint local do socket. Desta forma, mensagens destinadas ao endereço IP e à 
porta do endpoint local são diretamente inseridas no buffer de recepção do respectivo socket. 


Vale ressaltar que o endereço IP associado ao endpoint local pode ser um endereço IP espe- 
cífico ou o endereço especial 0.0.0.0. Conforme foi visto, geralmente o endereço especial 
0.0.0.0 é associado ao endpoint local. Como o cliente não é previamente conhecido, o ser- 
vidor não precisa definir o endpoint remoto do socket. Portanto, após configurar o endpoint 
local (bind), o servidor está pronto para receber e processar mensagens dos clientes. 


Para receber mensagens, o servidor utiliza a função recvfrom. Quando uma mensagem é 
recebida, a função recvfrom retorna o conteúdo da mensagem, bem como a identificação do 
endpoint remoto do cliente que a enviou. Após receber uma mensagem, o servidor pro- 
cessa a mensagem e envia a respectiva resposta usando a função sendto, informando como 
parâmetro o endpoint remoto do cliente, que foi previamente recebido através da função 
recvfrom. Após processar uma mensagem, o servidor volta a ativar a função recvfrom para 
receber novas mensagens. 


No outro lado, logo após criar o socket UDP, o cliente está pronto para enviar mensagens 

ao servidor. Para tal, o cliente deve conhecer o endpoint remoto do servidor, ou seja, o 
endereço IP e a porta do servidor. Para enviar mensagens, o cliente utiliza a função sendto, 
informando o endpoint remoto do servidor. Em seguida, o cliente usa a função recvfrom para 
receber a respectiva resposta do servidor. 


Lembre-se de que o cliente adota uma porta qualquer não reservada. Portanto, ao con- 
trário do servidor, o cliente não precisa usar a função bind para associar um número de 
porta específica ao endpoint local do socket criado. No cliente, a associação de uma porta 
arbitrária ao endpoint local é transparentemente realizada pelo próprio sistema operacional 


durante a execução da função sendto. 
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Após interagir com o servidor, usando as funções sendto e recvfrom, o cliente fecha o socket 
com a função close, e depois finaliza a sua execução. Por outro lado, como as requisições dos 
vários clientes devem ser continuamente processadas, o servidor raramente utiliza a função 
close, exceto quando detecta alguma situação especial que requer a reinicialização do socket 
ou do próprio servidor. 


Clientes e servidores TCP 


o Orientados à conexão. a 


o Baseados em circuitos virtuais. 


a Criam novo socket a cada nova requisição. 


A figura 9.5 mostra o modelo clássico de implementação de clientes e servidores TCP. 
Da mesma forma que clientes e servidores UDP, inicialmente, o cliente e o servidor TCP 
criam e obtêm a permissão de uso de seus respectivos sockets usando a função socket. 


No entanto, como parâmetro desta função, o cliente e o servidor informam que o socket Figura 9.5 
Modelo de imple- 
mentação de 
clientes e servi- 
descritor do socket, que o identifica internamente no sistema operacional. dores TCP. 


deve adotar o serviço de transporte orientado à conexão. Internamente, o sistema opera- 


cional mapeia este serviço para o protocolo TCP. A função socket retorna como resultado o 


Servidor TCP 


Sincronização _ Comunicação 


Cliente TCP 





Como servidores UDP, servidores TCP também adotam uma porta reservada e conhecida. 
No entanto, como já sabemos, a função socket não define o número da porta associada ao 
endpoint local do socket criado. De forma similar ao servidor UDP, o servidor TCP deve usar 
a função bind, informando o endereço IP e o número da porta específica que devem ser 
associados ao endpoint local do socket. O endereço IP associado ao endpoint local pode ser 
um endereço específico ou o endereço especial 0.0.0.0. No entanto, geralmente, o endereço 
especial 0.0.0.0 é associado ao endpoint local. Como o cliente não é previamente conhecido, 


o servidor não precisa definir o endpoint remoto do socket. 


Neste ponto, o socket do servidor ainda se encontra no estado closed. Para indicar que está 
passivamente aguardando por requisições de conexão, o socket TCP deve estar no estado 
listen. Para tal, o servidor utiliza a função listen, mudando o socket para o estado listen. 

A partir de então, o socket está pronto para receber requisições de conexão. Desta forma, 
requisições de conexão destinadas ao endereço IP e à porta do endpoint local são direta- 


mente endereçadas ao respectivo socket. 


Para aguardar por requisições de conexão, o servidor utiliza a função accept, que bloqueia 


o processo servidor até a chegada de uma requisição de conexão. Quando uma requisição 
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o descritor deste novo socket para o processo servidor. Neste ponto, o servidor possui dois 
sockets: o socket original e o novo socket. 


O socket original não é modificado e, portanto, ainda se encontra no estado listen. O endpoint 
local é aquele configurado com a função bind, e o endpoint remoto não está definido. Por 
outro lado, o novo socket encontra-se no estado established, indicando que está conectado 
ao cliente. O endpoint local do novo socket possui o endereço IP e a porta do servidor. Já o 
endpoint remoto do novo socket possui o endereço IP e a porta do cliente. O sistema ope- 
racional utiliza as informações do segmento TCP e o respectivo datagrama IP, que transpor- 
taram a requisição de conexão, para configurar os endereços IP e os números de portas dos 
endpoints local e remoto do novo socket. Logo, os endpoints local e remoto do novo socket 


possuem endereços IP e portas específicas. 


Neste estágio, o servidor está pronto para receber e processar mensagens do cliente. 

O servidor interage com o cliente usando o novo socket, enquanto o socket original é usado 
apenas para aguardar novas requisições de outros clientes. É importante ressaltar que 
existem diferentes formas do servidor usar estes dois sockets. Adiante vamos identificar e 


avaliar as principais formas. 


Para receber mensagens, o servidor utiliza a função read no novo socket. Após receber uma 
mensagem, o servidor processa a mensagem e envia a respectiva resposta via função write 
no novo socket. Após processar uma mensagem, o servidor volta a ativar a função read no 


novo socket para receber outra mensagem do cliente. 


Vale ressaltar que, diferentemente das funções recvfrom e sendto, que explicitamente 
informam o endpoint remoto do socket, as funções read e write não informam o endpoint 
remoto, pois ele já foi previamente configurado pelo sistema operacional durante o estabe- 


lecimento da conexão. 


Após interagir com o cliente usando as funções read e write, o servidor fecha o novo socket 
através da função close. Em seguida, como as requisições dos vários clientes devem ser con- 
tinuamente processadas, o servidor volta a ativar a função accept no socket original. 

O servidor raramente utiliza a função close no socket original, exceto quando detecta 


alguma situação especial que requer a reinicialização do socket ou do próprio servidor. 


No outro lado, após criar o socket TCP usando a função socket, o cliente deve ativamente 
estabelecer uma conexão com o servidor. Para tal, o cliente utiliza a função connect, infor- 
mando como parâmetro o endereço IP e a porta específica do endpoint remoto do servidor. 
Após estabelecer a conexão, o sistema operacional altera o estado do socket ativo para 
established. Observe que as funções connect e accept representam um ponto de sincroni- 


zação entre o cliente e o servidor. 


Após o estabelecimento da conexão, o socket do cliente possui endpoints local e remoto com 
endereços IP e portas definidas. Lembre-se de que o cliente adota uma porta qualquer não 
reservada. Portanto, da mesma forma que o cliente UDP, o cliente TCP também não precisa 
usar a função bind para associar um número de porta específica ao endpoint local do socket 
criado. No cliente TCP, a associação de uma porta arbitrária ao endpoint local é transparente- 


mente realizada pelo próprio sistema operacional durante a execução da função connect. 


Neste ponto, o cliente está pronto para interagir com o servidor. Para enviar mensagens ao 
servidor, o cliente utiliza a função write. Em seguida, o cliente usa a função read para receber a 


respectiva resposta do servidor. Após interagir com o servidor, usando as funções write e read, 
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Em resumo, o processo servidor realiza as seguintes atividades: cria um socket TCP com a 
função socket; associa o endereço IP e o número da porta ao endpoint local com a função 
bind; sinaliza que o socket está pronto para receber requisições de conexão com a função 
listen; aguarda requisições de conexão com a função accept; interage com o cliente usando 
as funções read e write no novo socket; fecha o novo socket ao final da interação com o 
cliente usando a função close; e, por fim, volta a aguardar requisições de conexão no socket 
original usando a função accept. 


No outro lado, o processo cliente realiza as seguintes atividades: cria um socket TCP com a 
função socket; estabelece uma conexão com o servidor usando a função connect; interage com 


o servidor usando as funções write e read; e, por fim, fecha o socket usando a função close. 


Servidores de aplicação 


a Servidor iterativo (single threaded) gJ 
a Trata requisições de um único cliente a cada instante. 
a Implementado como um único processo. 
a Servidor concorrente (multi-threaded) 
a Trata simultaneamente requisições de vários clientes. 
a Implementado com vários processos independentes. 


m Cada processo trata individualmente as requisições de um determinado cliente. 


Na maioria das vezes, os clientes iniciam a execução, trocam mensagens com um único 
servidor e depois terminam a execução. Por outro lado, geralmente, os servidores executam 
indefinidamente, enquanto o sistema está operacional, tratando as várias requisições dos 
diversos clientes. Portanto, o projeto de servidores é, geralmente, bem mais complexo que 
o projeto de clientes, requerendo, assim, um estudo mais detalhado das estratégias de 
projeto e implementação. 


Após receber uma requisição de conexão através da função accept, o servidor obtém o 
socket original, no estado listen, e o novo socket, que se encontra no estado established. 
Além disso, sabemos que o servidor utiliza o novo socket para comunicar-se com o cliente 

e o socket original apenas para aguardar novas requisições de outros clientes. No entanto, 
dependendo da carga de requisições do serviço e da carga de processamento destas 
requisições, a implementação do servidor pode ser estruturada adotando dois modelos 
diferentes de tratamento de requisições: o modelo iterativo e o modelo concorrente. Vale 
ressaltar que não existe uma categorização para os clientes, pois eles não sabem se estão se 
comunicando com um servidor iterativo ou concorrente. 


Servidor iterativo 





Adequado para serviços com reduzida taxa de requisições e serviços cujas requisições 
possuem baixa carga de processamento. J 


No modelo iterativo, o servidor trata requisições de um único cliente a cada instante. Neste 
modelo, o servidor é implementado como um único processo, que trata individualmente cada 
requisição. Em função disso, o modelo iterativo é também denominado modelo single-threaded. 


A figura 9.6 ilustra a estrutura de um servidor iterativo. Nela, podemos identificar as funções 
que atuam no socket original e no novo socket, que é retornado pela função accept. 


Servidor TCP 


==> Socket original 
=> Novo socket 


Figura 9.6 
Tratamento de 
requisições: ser- 
vidor iterativo. 


Figura 9.7 
Tratamento de 
requisições: ser- 
vidor concorrente. 


Servidor TCP 





Como já sabemos, o processo servidor aguarda por requisições de conexão usando a função 
accept. Após receber uma requisição, o servidor interage com o cliente ativando as funções 
read e write no novo socket. Ao final desta interação, o servidor fecha o novo socket com a 
função close. A seguir, o servidor reativa a função accept no socket original e volta a aguardar 
pela próxima requisição de conexão. Observe que o servidor iterativo processa requisições 


de um único cliente a cada instante. 


Considerando que um servidor iterativo atende um único cliente por vez, o modelo itera- 
tivo é adequado apenas para serviços com taxa reduzida de requisições e serviços cujas 
requisições possuem baixa carga de processamento. Desta forma, existe uma grande pro- 
babilidade de uma requisição não ser retardada ou descartada enquanto outra está sendo 


processada pelo servidor. 


Servidor concorrente 


Adequado para serviços com elevada taxa de requisições e serviços cujas requisições a 


possuem alta carga de processamento. | 


Por outro lado, no modelo concorrente, o servidor trata requisições de varios clientes simultane- 
amente. Neste modelo, o servidor é implementado como vários processos ou threads indepen- 
dentes, onde cada um deles é responsável por tratar individualmente as requisições de um 
determinado cliente. Em função disso, o modelo concorrente é também denominado modelo 


multi-threaded. A figura 9.7 ilustra a estrutura de um servidor concorrente. 


read write close 


socke In Iisten 
<= 


= Socket original 
==> Novo socket 


Sere ae 


Como no modelo iterativo, no modelo concorrente, o processo servidor (mestre) também 





aguarda por requisições de conexão usando a função accept. Entretanto, diferentemente 
do modelo iterativo, no modelo concorrente, o servidor cria um novo processo ou thread 


(escravo) após a chegada de uma requisição de conexão. 


O mestre é responsável por tratar as novas requisições de conexão de outros clientes. Para 
tal, o mestre reativa a função accept no socket original, que se encontra no estado listen. Por 
outro lado, o escravo é responsável por gerenciar a comunicação com o cliente que solicitou 


o estabelecimento da conexão. Para tal, o escravo interage com o cliente ativando as funções 
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Observe que o mestre está sempre em execução. Por outro lado, o escravo interage com um 
único cliente e, em seguida, finaliza sua execução. Seguindo este procedimento, em um dado 
momento, existe um único processo mestre, que aguarda por requisições de conexão de 
outros clientes, e podem existir vários processos escravos, que são responsáveis por tratar 
as requisições dos seus respectivos clientes. 


Considerando que um servidor concorrente atende a diversos clientes de forma simul- 
tânea, o modelo concorrente é adequado para serviços com elevada taxa de requisições e 
serviços cujas requisições possuem alta carga de processamento. A vantagem do servidor 
concorrente é que ele ativa outros processos para tratar cada requisição. Portanto, cada 
cliente possui seu próprio servidor (processo ou thread) dedicado e suas requisições são 
processadas concorrentemente. 


Compartilhamento de portas 





o Socket do mestre: 
m Está sempre no estado listen. 
m Endpoint local possui o endereço especial 0.0.0.0 e a porta específica do servidor. 
= Endpoint remoto possui o endereço especial 0.0.0.0 e a porta "*”. 
a Sockets dos escravos: 
m Estão sempre no estado established. 
a Endpoints locais possuem o endereço IP da estação e a porta específica do servidor. 
m Endpoints remotos possuem os endereços IP e as portas dos respectivos clientes. 
a Servidor concorrente: 
m Existe um único socket no estado listen. 
a Somente processa segmentos SYN. 
m Podem existir diversos sockets no estado established. 
a Somente processam segmentos de dados. 
a Endpoints local e remoto desses sockets devem ser diferentes. 


Em um servidor concorrente, cada processo ou thread usa seu próprio socket. O socket do 
mestre está sempre no estado listen e, geralmente, seu endpoint local possui o endereço 
IP especial 0.0.0.0 e a porta específica do servidor. Por outro lado, os sockets dos escravos 
encontram-se no estado established e seus endpoints locais possuem o endereço IP da 
estação e a porta específica do servidor. Consequentemente, todos os sockets de um ser- 
vidor concorrente possuem o mesmo número de porta. Além disso, geralmente, todos os 
escravos de um servidor concorrente possuem o mesmo endpoint local. 


Embora possam existir vários sockets cujos endpoints locais adotam o mesmo número de 
porta, o sistema operacional assegura que os endpoints remotos destes sockets são sempre 
diferentes. Em geral, o socket do mestre possui o endereço especial 0.0.0.0 e a porta “*” 
associada ao endpoint remoto, permitindo que o socket possa se conectar com qualquer 
cliente. Por outro lado, os sockets dos escravos possuem os endereços IP e os números das 


portas dos seus respectivos clientes associados aos seus endpoints remotos. 


Em resumo, para uma determinada porta, pode existir apenas um único socket no estado 
listen. No entanto, para esta mesma porta, podem existir diversos sockets no estado 
established, desde que seus respectivos endpoints local e remoto sejam distintos. 


Figura 9.8 
Compartilhamento 
de portas. 


Vale ressaltar que, embora não seja usual, para uma determinada porta, também é possível 
existirem diversos sockets no estado listen, desde que cada um deles possua um diferente 


endereço IP associado ao endpoint local. 


Para cada segmento TCP recebido, a entidade TCP identifica os endpoints local e remoto. 
Se o segmento transporta uma requisição de conexão, a entidade TCP o encaminha ao res- 
pectivo socket no estado listen. Caso contrário, se o segmento transporta dados, a entidade 
TCP o envia ao respectivo socket no estado established. Portanto, o socket no estado listen 
somente processa segmentos que transportam requisições de conexão. Por outro lado, os 
demais sockets no estado established somente recebem/enviam segmentos de dados. 


No exemplo da figura 9.8, ao receber um segmento SYN, cujos endpoints local e remoto são 
(150.1.20.1, 25) e (10.1.5.1, 62789), a entidade TCP o encaminha ao socket no estado listen. Por 
outro lado, ao receber um segmento TCP de dados, cujos endpoints local e remoto são 
(150.1.20.1, 25) e (200.50.2.10, 58461), a entidade TCP o entrega ao segundo socket no estado 


established, presente na figura 9.8. 


> netstat -tan 





Proto Recv-Q Send-Q Local Address Foreign Address State 

tcp 0 © 0:0.0-0:25 OROMOMOR LISTEN 

tcp 0 OS OFZ Oreo Aral Oe S055 60a ES TABS TIED) 
tcp 0 I501.20,1825 RS OZ 10:56461_ ESTABLISHED 
tcp 0 ES ORI O PIE DS OR Oeil Z0 60/49 Ga ESTABLISHED 





Gerenciamento de conexões TCP 


Fila de requisições: 

a Associada a sockets TCP no estado listen. 

a Armazena requisições de conexão que já foram aceitas pela entidade TCP. 
m Processamento da requisição é realizado pela entidade TCP, e não pelo servidor. 
m Requisição presente na fila ainda não foi aceita pelo servidor. 


m Requisição somente é aceita e removida da fila quando o servidor ativa a 


função accept. 





a Possui capacidade fixa, mas pode ser configurada pelo servidor com a função listen. 


Mesmo em um servidor concorrente, quando a taxa de requisições de conexão é demasia- 
damente elevada, diversas requisições de conexão podem ser recebidas enquanto o pro- 
cesso ou thread mestre está criando o processo ou thread escravo, ou o sistema operacional 
está escalonando o processador a outros processos de maior prioridade. Nestes casos, tais 
requisições de conexão não serão aceitas pelo servidor e os respectivos clientes, erronea- 


mente, concluirão que o servidor não está operacional. 


Para evitar estes casos, o sistema operacional implementa um mecanismo de tratamento de 
requisições de conexão, associando uma fila de requisições de conexão a cada socket TCP 
que se encontra no estado listen. Como o protocolo UDP não adota o conceito de conexão, a 


fila de requisições é usada apenas para sockets TCP. 


A fila de requisições apenas armazena, temporariamente, as requisições de conexão que já 
foram aceitas pela entidade TCP, ou seja, o procedimento three-way handshake foi realizado 


com sucesso. Observe que, neste esquema, o processamento das requisições de conexão 
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é realizado diretamente pela entidade TCP, residente no sistema operacional, e não pelo 
processo servidor. No entanto, as requisições presentes na fila ainda não foram aceitas 
pelo processo servidor. Uma requisição presente na fila somente é aceita e removida da fila 
quando o processo servidor ativa a função accept. 


A fila de requisições possui uma capacidade fixa, mas configurável. O servidor pode especi- 
ficar o tamanho da fila de requisições usando a função listen. Vale ressaltar que o tamanho 
da fila de requisições não tem qualquer relação com o número máximo de conexões que 
podem ser simultaneamente estabelecidas pelo sistema, ou com o número de clientes que o 
servidor concorrente pode tratar simultaneamente. 


Quando uma requisição de conexão é recebida e a fila de requisições está cheia, a requi- 
sição é simplesmente ignorada e nenhum segmento de resposta é devolvido. Desta forma, 
o cliente retransmite a requisição de conexão, e, eventualmente, esta retransmissão poderá 


encontrar a fila de requisições com disponibilidade para aceitar novas requisições. 


Multiplicidade de serviços 





o Servidor de um único serviço: aguarda requisições de conexão em um único socket, 
que possui uma única porta associada ao endpoint local (implementação baseada 
na função accept). 


ao Servidor de múltiplos serviços: aguarda requisições de conexão em diversos 
sockets, que possuem diferentes portas associadas aos respectivos endpoints locais 
(implementação baseada na função select). 


Para reduzir o número de processos executando em um determinado sistema, e, assim, 
tornar mais eficiente o escalonamento de processos realizado pelo sistema operacional, 

a interface socket permite que um único processo aguarde requisições de conexão em 
diversos sockets simultaneamente. Desta forma, um único processo servidor pode oferecer 
diversos serviços. 


Em função desta facilidade, podemos definir dois tipos de servidores: o servidor de um 
único serviço e o servidor de múltiplos serviços. No primeiro caso, o processo servidor 
aguarda requisições de conexão em um único socket, que possui uma única porta associada 
ao endpoint local. No segundo caso, o processo servidor aguarda requisições de conexão 
em diversos sockets, onde em cada um deles o endpoint local está associado a uma porta 
diferente. 


A implementação de um servidor de um único serviço é realizada usando a função accept, 
como foi comentado. Para suportar a implementação de um servidor de múltiplos serviços, 
a interface socket provê a função select, que recebe como parâmetro o conjunto de sockets, 


nos quais o servidor deve aguardar requisições de conexão. 


Em um servidor de múltiplos serviços, inicialmente, o servidor cria todos os sockets dese- 
jados com a função socket, ativa a função bind em cada um destes sockets para configurar 
seus endpoints locais, sinaliza que estes sockets estão prontos para receber requisições de 
conexão com a função listen, e, então, ativa a função select para aguardar por requisições de 
conexão em algum destes sockets. 


Da mesma forma que a função accept, a função select bloqueia a execução do servidor até que 
uma requisição de conexão seja recebida em alguma das portas associadas aos 
endpoints locais destes sockets. Após receber uma requisição em algum destes sockets, o pro- 


cesso servidor adota um procedimento semelhante ao descrito para o servidor concorrente. 


Por exemplo, em sistemas Linux, o processo xinetd implementa um servidor de múltiplos 
serviços. Na inicialização do sistema, este processo avalia um conjunto de arquivos de 
configuração que, por default, estão presentes no diretório /etc/xinetd.d. Cada um destes 
arquivos descreve um serviço que deve ser oferecido pelo xinetd, indicando, por exemplo, o 
nome do serviço, o protocolo de transporte, a porta adotada pelo serviço e o comando a ser 


executado para tratar cada requisição dos clientes. 
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=# Roteiro de Atividades 9 


Atividade 9.1- Serviços e portas 


Um processo servidor negocia com o sistema operacional a possibilidade de abrir e usar 
uma determinada porta, que foi previamente reservada para o serviço oferecido pelo ser- 
vidor. Por sua vez, 0 sistema operacional deve assegurar que, quando um processo solicita a 
criação de uma determinada porta, somente esse processo estará associado aquela porta. 
Considere que um determinado processo está oferecendo o serviço X na porta Y, adotando 


o serviço de datagramas da camada de transporte. 


1. Outro processo, também adotando o serviço de datagramas da camada de transporte, 


pode oferecer o mesmo serviço X em outra porta Z? 








2. Outro processo, adotando o serviço de circuito virtual da camada de transporte, pode 


oferecer o mesmo serviço X na mesma porta Y? Explique. 








Atividade 9.2 - Monitorando portas TCP 


O administrador de rede de uma universidade, usando o comando netstat, está monito- 


rando as conexões do servidor web, que usa a porta TCP 80. 


> netstat -tan 








Proto Recv-Q Send-Q Local Address Foreign Address State 

tcp 0 0 MORROS 00.003 LISTEN 

tcp 0 0 0.0.0.0:80 OTOMORO LISTEN 

tcp 0 0 IBO2 MO e25 ISO 50,1 2OeavAGi ESTABCISHED 
tcp 0 0 ISO 210,125 192,20.2.10261296 ESTABLISHED 





1. Na primeira execução do comando netstat, a saída obtida é mostrada na figura anterior. 


O servidor web está ativo? Existem clientes conectados neste servidor? Explique. 
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2. Algum tempo depois, o administrador executou novamente o comando netstat, obtendo a 


saída mostrada na figura abaixo. Existem clientes conectados nesse servidor? Explique. 


> netstat -tan 


Proto 


tcp 


tcp 


tcp 





tcp 


Recv-Q 


0 


0 


0 


0 


Send-Q 
0 


0 


Local Address 


0.0.0.0:25 


0.0.0.0:80 


150,2. 10. 1:680 


150-210-1560 


Foreign Address 


OROROROR= 


OROROROE 


192-10; 1-1355272 


15010.50, 163127 


State 


LIST 


LTS 


EN 





TEN 


ESTABLISHED 





ESTABLISHED 








Atividade 9.3 — Portas TCP e UDP 


O administrador de um determinado sistema foi recém-contratado e está tentando iden- 


tificar os serviços que estão sendo oferecidos em uma determinada estação. Para tal, ele 


executou o comando netstat, cuja saída é mostrada na figura a seguir. 


> netstat -tuan 


Proto 
tcp 
tcp 
tcp 
tcp 
tcp 
tcp 


udp 





udp 


0 


0 


0 


0 


Recv-Q Send-Q 


0 


0 


0 


0 


Local Address 


00-0-0525 


0.0.0.0:80 


192-10133525 


DONS ZE 


192 Oj 15325 


192. O IL e560 


ORORORO EY 


Foreign Address 


0.0.0.0:* 


OP ORO A Ores 


ONOROR O 


200,20- 1.1:55120 


192-10- 1363472 


150: 10:50. 1:5/387 


00-00 


192. OBS 000 0 


State 


LILSTE 


LISTE 





LISTE 





ESTAB 


ESTAB 





ESTAB 


LISHED 


LISHED 





LISHED 


1. Quantos servidores estão em execução nessa estação? Quais os protocolos de transporte 


adotados por esses servidores? 








2. Identifique os sockets usados para aguardar requisições de conexão 








3. Quantos clientes estão conectados a cada servidor? 





Arquitetura e Protocolos de Rede TCP-IP 





X 


4. Identifique os sockets usados pelos servidores para interagir com seus respectivos clientes. 








Atividade 9.4 - Processamento de segmentos TCP 


Um determinado sistema possui três interfaces de rede, cujos endereços IP são: 192.10.1.33, 
192.10.1.65 e 192.10.1.97. Considere que esse sistema possui os sockets TCP ilustrados na 


figura da atividade anterior. 


1. Esse sistema recebeu um segmento SYN, cujas portas origem e destino são 56.267 e 25. Esse 
segmento TCP foi transportado em um datagrama IP, cujos endereços origem e destino são 
192.10.2.5 e 192.10.1.97. Para qual socket este segmento SYN será encaminhado? 











2. Considere que o endereço destino do datagrama IP do item anterior (item 1) é 192.10.1.33. 


Nesse caso, o segmento SYN será encaminhado ao mesmo socket? Explique. 








3. Esse sistema recebeu e aceitou outro segmento TCP, cujas portas de origem e destino são 
63.472 e 25. Esse segmento TCP foi transportado em um datagrama IP, cujos endereços 
origem e destino são 192.10.1.1 e 192.10.1.65. Esse segmento TCP transporta dados ou 


uma requisição de conexão? 











Atividade 9.5 — Servidores iterativos e concorrentes 


Usando o comando netstat, o administrador de um determinado sistema vem monitorando 
o uso de dois servidores TCP, cujas portas são X e Y. Em um único caso, o administrador per- 
cebeu que a porta X estava sendo usada, simultaneamente, por cinco sockets, um deles no 
estado listen e os demais no estado established. Na porta Y, mesmo quando o administrador 
solicitou que clientes estabelecessem conexões simultâneas com o servidor, o adminis- 
trador percebeu que nunca existiram mais que dois sockets associados a essa porta, sendo 
um no estado listen e outro no estado established. Além disso, o administrador também 


observou que um cliente somente é atendido após o outro fechar a conexão. 


Esses servidores são implementados como servidores iterativos ou concorrentes? Explique. 
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Protocolos de aplicação 










Descrever o serviço de nomes (DNS), o serviço de correio eletrônico (SMTP) e o 
serviço web (HTTP). 


objetivos 












Protocolos da camada de aplicação e suas caraterísticas, funcionalidades 


e componentes das principais aplicações usadas na arquitetura TCP/IP. 







SO}d9U09 


Protocolos da camada de aplicação 


Este capítulo trata de protocolos da camada de aplicação, abordando as características, fun- 
cionalidades e componentes das principais aplicações usadas na arquitetura TCP/IP: serviço 
de nomes (DNS - Domain Name System); serviço de correio eletrônico (SMTP - Simple Mail 
Transfer Protocol); e serviço web (HTTP - Hypertext Transfer Protocol). 


Usa os serviços da camada de transporte para permitir a comunicação entre os 


processos de aplicação. 

a Serviço de datagramas. 

a Serviço de circuito virtual. 

Desenvolvedor de aplicação deve selecionar o serviço de transporte a ser adotado. 


a Serviço de aplicação sem conexão: adota o protocolo UDP. 








a Serviço de aplicação com conexão: adota o protocolo TCP. 


Vamos conhecer um serviço de aplicação que utiliza o serviço de datagramas da camada 
de transporte, especificamente o protocolo UDP e dois serviços de aplicação que utilizam o 
serviço de circuito virtual, especificamente o protocolo TCP. Veremos as principais caracte- 
rísticas dos serviços de aplicação orientados e não orientados à conexão. Serão estudadas 
as características, funcionalidades e componentes do serviço de nomes (DNS - Domain 
Name System), que utiliza o protocolo de transporte UDP, cujo principal objetivo é traduzir 
nomes de estações para endereços IP. A seguir estudaremos os serviços de correio ele- 
trônico (SMTP - Simple Mail Transfer Protocol) e serviço Web (HTTP - Hypertext Transfer 


Protocol), que utilizam o protocolo de transporte TCP. 


Na arquitetura TCP/IP, a camada de aplicação usa os serviços da camada de transporte para 
permitir a comunicação entre os processos de aplicação. Um processo de aplicação interage 
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No projeto de um serviço de aplicação, uma das primeiras decisões do desenvolvedor é 
selecionar o serviço de transporte a ser adotado. 


Como já sabemos, a camada de transporte oferece os serviços de datagramas e de circuito 
virtual. No serviço de datagramas, os processos se comunicam usando o protocolo UDP, 
que não é orientado à conexão e oferece um serviço de transferência de dados não confi- 
ável. Neste caso, as mensagens geradas pelos processos de aplicação são encapsuladas em 
datagramas UDP independentes, compondo um conjunto de mensagens individuais, que 
podem não chegar ao destino ou chegar fora da sequência original. Serviços de aplicação 
que adotam o protocolo UDP são denominados serviços sem conexão. 


Por outro lado, no serviço de circuito virtual, os processos se comunicam usando o pro- 
tocolo TCP, que é orientado à conexão e oferece um serviço confiável de transferência de 
dados. Neste caso, as mensagens geradas pelos processos de aplicação são encapsuladas 
em segmentos TCP, compondo um fluxo contínuo de dados que são entregues ao destino 
sem erros e em sequência. Serviços de aplicação que adotam o protocolo TCP são denomi- 
nados serviços com conexão. 


Vamos estudar um exemplo de serviço de aplicação não orientado à conexão, que, portanto, 
adota o protocolo UDP. Veremos também exemplos de serviços de aplicação orientados à 
conexão, que adotam o protocolo TCP. 


DNS 


o Implementa o serviço de nomes da arquitetura TCP/IP. a2 


ao Implementado em um conjunto hierárquico e geograficamente distribuído de servi- 
dores de nomes. 


a Provê um esquema para atribuir nomes às estações. 


ao Especifica um mecanismo de mapeamento automático de nomes de estações para 
seus respectivos endereços IP. 


oa Esquema de atribuição de nomes. 

m Define a sintaxe dos nomes. 

m Define as regras de delegação de autoridade para gerenciamento de nomes. 
a Mecanismo de mapeamento. 


m Define uma base de dados distribuída que associa um determinado nome a um 
conjunto de atributos. 


a Adota um algoritmo de resolução distribuído que mapeia nomes para seus atributos. 


m Especifica um protocolo de aplicação que viabiliza a resolução de nomes. 


Datagramas IP adotam endereços IP para identificar as estações origem e destino. Embora 
os endereços representem uma forma compacta de especificar as estações comunicantes, 
os usuários preferem identificá-las através de nomes. Consequentemente, para facilitar 

o uso dos diversos serviços, a arquitetura TCP/IP deve prover um serviço de nomes que 
permita a qualquer processo de aplicação obter o endereço IP de uma estação a partir do 


seu respectivo nome. A 
P Mapeamento direto 


Na arquitetura TCP/IP, o serviço de nomes, denominado Domain Name System (DNS), provê Mapeamento auto- 
mático de um nome 
de estação para seu res- 
mecanismo de mapeamento direto de nomes de estações para seus respectivos endereços  pectivo endereço IP. 


um esquema para atribuir nomes únicos às estações conectadas à internet e especifica um 


Sintaxe de nomes 


Conjunto de regras 
que definem como 

os nomes DNS 
devem ser escritos 


Delegação 
de autoridade 


Processo no qual 

a responsabilidade 

do gerenciamento de 
nomes das várias zonas 
é delegada às diversas 
instituições conectadas, 
não existindo uma 
entidade central que 
gerencia todo o espaço 
de nomes. 


Base de dados 
distribuída 


Repositório de 
informações que 
armazena dados em 
servidores geografica- 
mente distribuídos. 


Mapeamento reverso 


Mapeamento do 
endereço IP para 
seu respectivo 
nome de estação. 





IP. O serviço de nomes da arquitetura TCP/IP é especificado nos RFCs 1034 e 1035, sendo 
complementado por outro conjunto de RFCs. 


No DNS, o esquema de atribuição de nomes define a sintaxe dos nomes, bem como as 








mecanismo de mapeamento é suportado por uma base de dados distribuída, um algoritmo 


de resolução distribuído e um protocolo de aplicação. 


A base de dados distribuída associa um determinado nome a um conjunto de atributos, 
por exemplo, o endereço IP. O algoritmo de resolução realiza o mapeamento dos nomes 
para seus respectivos atributos, mantidos na base de dados. Por sua vez, o protocolo de 
aplicação DNS permite a comunicação de clientes e servidores de nomes com o objetivo de 
realizar a resolução de nomes. O protocolo DNS utiliza a porta UDP 53. No entanto, como 


veremos, o DNS também utiliza a porta TCP 53 para alguns tipos de operações. 


O DNS define um serviço de nomes implementado em um conjunto hierárquico e geogra- 
ficamente distribuído de servidores de nomes. Cada servidor de nomes é um processo 
de aplicação que mantém sua própria base de dados e permite que os clientes e outros 
processos de aplicação (locais ou remotos) possam consultar suas informações. Nenhum 


servidor de nomes mantém todas as informações do serviço de nomes. 


Ao contrário dos demais serviços que, geralmente, são utilizados diretamente pelos usu- 
ários, o DNS fornece facilidades básicas que são utilizadas de forma transparente pelos 


demais serviços, para traduzir nomes de estações para seus respectivos endereços IP. Por 


exemplo, quando o usuário informa a URL www.di.ufpb.br/index.html, antes de contatar o 





Vale ressaltar que o DNS não realiza apenas o mapeamento do nome da estação para seu 
respectivo endereço IP, que é apenas um tipo de atributo mantido na base de dados distri- 
buída. Por exemplo, o DNS também permite o mapeamento reverso do endereço IP para 


seu respectivo nome de estação. 


A seguir, vamos estudar os principais aspectos do DNS. No entanto, por ser um sistema de razo- 


ável complexidade, não serão apresentados detalhes de configuração dos servidores de nomes. 


Hierarquia de nomes 
Espaço de nomes DNS é hierárquico e tem o formato de uma árvore. 
ao Notação utilizada: 

m Araiz da árvore é“.” (root). 

a Os nós intermediários são os dominios. 

m Cada nó folha representa uma estação. 

m O nome de cada nó é uma sequência de rótulos. 
a Os domínios podem ser: 


m Organizacionais. 


m Geográficos. 





m ARPA. 
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Figura 10.1 
— > 65.10.168.192.in-addr.arpa Espaço de nomes. 


Como ilustrado na figura 10.1, o espaço de nomes DNS possui uma organização hierárquica. 
Cada nó da árvore hierárquica tem um rótulo de até 63 caracteres. A raiz da árvore é um 
nó especial, cujo rótulo é representado por um ponto (root - raiz). Cada nó intermediário é 


denominado um domínio. Cada nó folha representa uma estação. 


O nome de um nó (domínio ou estação) é a sequência de rótulos, separados por ponto, iniciando 
no próprio nó e concluindo na raiz. Por exemplo, br e rnp.br são nomes de domínios, enquanto 
www.rnp.br é um nome de estação. Vale ressaltar que, geralmente, a literatura TCP/IP adota o 


termo nome de domínio (domain name) para designar o nome de ambos os tipos de nós. 


Todos os nós devem possuir um nome de domínio único. Desta forma, dois ou mais nós Nome de domínio 


não devem ter o mesmo rótulo, quando associados ao mesmo nó de nível superior. No Sequência de rótulos, 
separados por ponto, 
iniciando no próprio nó 
ciados a diferentes nós de nível superior. Por exemplo, na figura 10.1, os nós que repre- econcluindo:na raiz 


entanto, o mesmo rótulo pode ser usado por dois ou mais nós, desde que estejam asso- 


sentam os domínios com e com.br possuem os mesmos rótulos, mas estão associados a 


diferentes nós de nível superior (raiz e br). 


Um nome de domínio que termina com um ponto denomina-se nome de domínio absoluto. 
Por exemplo, www.rnp.br é um nome de domínio absoluto. O serviço DNS somente resolve 


nomes de domínio absolutos. Portanto, um nome de domínio incompleto, que não termina 


com um ponto, precisa ser completado para tornar-se um nome de domínio absoluto. 


A forma de completar nomes de domínios depende da implementação DNS adotada. Geral- 
mente, um nome de domínio com dois ou mais rótulos já é considerado um nome de domínio 
absoluto pela maioria das implementações, mesmo que não termine com um ponto. Por 
outro lado, um nome de domínio que possui um único rótulo deve ser complementado com 
um sufixo, tornando-se um nome de domínio absoluto. Por exemplo, o nome www pode ser 
completado com o sufixo rnp.br, tornando-se o nome de domínio absoluto www.rnp.br. 


Conceitualmente, os domínios no nível mais alto da árvore (imediatamente abaixo da raiz) 


são divididos em três grupos: 


a Dominios organizacionais - compostos por rótulos de três ou mais caracteres que 
designam as áreas de atuação das instituições, profissionais e indivíduos: aero, coop, biz, 
com, edu, gov, info, int, mil, museum, name, net, org, pro. 


a Dominios geográficos - compostos por rótulos de dois caracteres que designam os 
códigos dos países: br, fr, uk, ... us. Padronizados pela norma ISO 3166. 


a Dominio arpa - dominio especial usado para realizar o mapeamento reverso de ende- 


reços IP para nomes de estações. 


Os domínios organizacionais, também denominados domínios genéricos, são usados 
principalmente por instituições norte-americanas. Já os domínios geográficos são usados 
por instituições dos demais países. No entanto, instituições que não são norte-americanas 
também podem usar os domínios organizacionais. Os únicos domínios organizacionais que 
são exclusivamente usados por instituições norte-americanas são os domínios gov e mil. 


Algumas instituições norte-americanas também usam o domínio geográfico us. 


Os domínios no nível mais alto da árvore também são conhecidos como Top Level Domain 


(TLD). Assim, o TLD de ww m é com. 





Muitos países criam subdomínios organizacionais locais no segundo nível da hierarquia de 
nomes. Por exemplo, no Brasil, os domínios com.br e gov.br designam instituições comerciais 
e governamentais, respectivamente. No caso particular do Brasil, por razões históricas, os 
nomes de domínio de algumas instituições são definidos no segundo nível da hierarquia. 
Por exemplo, os domínios rnp.br e ufpb.br são adotados pela Rede Nacional de Ensino e 
Pesquisa (RNP) e Universidade Federal da Paraíba (UFPB), respectivamente. 


Na hierarquia de domínios, o domínio in-addr.arpa é definido com o propósito de realizar 

o mapeamento reverso de endereços IP para os respectivos nomes de estações. Para um 
dado endereço A.B.C.D, o domínio imediatamente inferior ao domínio in-addr.arpa deve ser 
o primeiro byte do endereço IP (A). Abaixo do domínio A, o próximo nível é o próximo byte 
(B), e assim por diante. Nomes de domínios são escritos do nível mais baixo para o nível 
mais alto. Portanto, o nome de domínio associado ao endereço A.B.C.D é D.C.B.A.in-addr. 
arpa. Por exemplo, o nome de domínio associado ao endereço 192.168.10.65 é 65.10.168.192. 


in-addr.arpa, como mostrado na figura 10.1. 


Na prática, o mapeamento reverso é bastante explorado como mecanismo de segurança auxi- 
liar. Por exemplo, alguns serviços mantêm arquivos de configuração que identificam os nomes 
das estações autorizadas a utilizá-los. Neste caso, ao receber uma requisição, tais serviços 
verificam se o endereço IP da estação requisitante pertence a uma estação autorizada. 


Delegação de autoridade 


ga 
A responsabilidade do gerenciamento dos nomes é delegada às diversas instituições 


conectadas à internet. 
o Não existe uma autoridade central que gerencie todo o espaço de nomes. 
a Divide o espaço de nomes em zonas. 
o Uma zona é uma sub-árvore do espaço de nomes. 
a Cada zona é composta por seus domínios e estações. 
o A delegação de autoridade é distribuída entre as zonas. 
a Cada zona é administrada por uma entidade autorizada. 
a A autoridade de uma zona tem autonomia para subdividi-la em subzonas menores. 


a A autoridade de uma zona pode delegar a autoridade das subzonas para 





diferentes entidades. 
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Sempre que ocorrem mudanças nas redes e estações conectadas à internet, a base de dados 
do serviço DNS deve ser manualmente atualizada. Em função da imensa quantidade de ins- 
tituições conectadas à internet, é impossível centralizar o gerenciamento de nomes em uma 
única entidade. Desta forma, deve-se pensar em um esquema de delegação de autoridade, 
no qual a responsabilidade do gerenciamento de nomes é delegada às diversas instituições 


conectadas, não existindo uma entidade central gerenciadora de todo o espaço de nomes. 


Para tal, no DNS, o espaço de nomes hierárquico é subdividido em zonas. Conceitualmente, 


domínios e estações. A delegação de autoridade é distribuída entre as várias zonas. Desta sub-árvore do sopa ço 
de nomes hierárquico, 


composta por seus 
zada, responsável pelo gerenciamento de seus nomes. domínios e estações. 


forma, cada zona é individualmente administrada por uma determinada entidade autori- 


A autoridade de uma zona tem autonomia para subdividi-la em subzonas menores. Além 
disso, a autoridade de uma zona pode delegar a autoridade das subzonas a diferentes enti- 
dades. Por exemplo, a zona ufpb.br, delegada à Universidade Federal da Paraíba, pode ser 
subdividida em subzonas menores, que são delegadas aos vários centros e departamentos. 
Neste caso, a autoridade da zona ufpb.br é responsável por administrar a criação e remoção 
de subdomínios de nível imediatamente inferior, bem como atribuir nomes às estações do 
domínio ufpb.br. Por sua vez, a autoridade de cada subzona, por exemplo di.ufpb.br, é res- 


ponsável por administrar seus subdomínios de nível inferior e suas respectivas estações. 


Autoridade Raiz 


a ICANN/IANA 
m Administração dos servidores raiz. 
m Delegam os diversos TLDs (Top Level Domain). 
ao Autoridade “br” 
a NIC.br/Registro.br 
m Responsável pelo .br e pelos dominios de 2º nível. 
a com.br 
a edu.br 
a gov.br 
O controle da zona raiz é exercido pela Internet Assigned Numbers Authority (IANA), que 
por sua vez é uma das entidades sob o controle da Internet Corporation for Assigned Names 
and Numbers (ICANN). A IANA é responsável pela administração dos dados contidos nos 
chamados servidores raiz (root servers), que são um conjunto de servidores de nomes, 
espalhados geograficamente pelo mundo, que respondem pela zona raiz. Estes servidores 
delegam os diversos TLDs para os servidores de outras instituições responsáveis por cada 
TLD. Por exemplo, o TLD br é delegado para um conjunto de servidores operados pelo 
Núcleo de Informação e Coordenação do Ponto BR (NIC.br). O registro de domínios dentro 
do TLD br é feito através do Registro.br, que é o executor do NIC.br para registros de domi- 


nios. O Registro.br é responsável também pelos domínios de 2º nível disponíveis no Brasil, 


como .com.br, .edu.br, .gov.br, entre outros. 


Consulta a0 DNS 


CJ 
Cada nome de domínio está associado a um conjunto de atributos, e cada atributo defi- 
nido por um registro de recurso (RR). | 


Registro de recurso 


Estrutura adotada 
pelo serviço de 
nomes para realizar a 
associação de nomes 
de domínios a seus 
diferentes tipos 

de atributos. 


Resolução de nomes 


Processo de tradução 
de um determinado 
nome para seu respec 
tivo endereço IP. 


Como foi dito, DNS não realiza apenas o mapeamento de nomes de estações para endereços 
IP. Na base de dados, cada nome de domínio está associado a um conjunto de atributos, cada 


um deles especificado através de um registro de recurso (RR - Resource Record). Desta forma, 


para um dado nome de domínio, diferentes tipos de informações podem ser solicitados. 


Existem cerca de 20 diferentes tipos de registros de recursos, dos quais alguns são obso- 
letos. Principais tipos de registros de recursos: 

a A- associa o nome da estação ao respectivo endereço IP. 

a PTR- associa o endereço IP ao respectivo nome da estação. 

a CNAME - define um nome alternativo, ou apelido (alias), para o nome da estação. 


a HINFO - indica o hardware e o sistema operacional da estação. 


a MX- configura o roteamento de mensagens do serviço de correio eletrônico. 





a NS- define os servidores de nomes do dominio. 


Os registros A e PTR são usados para realizar os mapeamentos direto e reverso, respectiva- 
mente. O mapeamento direto realiza a resolução de nomes de estações para seus respec- 


tivos endereços IP. Por outro lado, o mapeamento reverso realiza a resolução de endereços 


IP para os respectivos nomes das estações. 


O registro CNAME é bastante usado para identificar uma estação pelo tipo de serviço ofere- 
cido. Por exemplo, a estação sol.rnp.br pode ter os nomes alternativos www.rnp.br e ftp.rnp.br, 


indicando que oferece os serviços web e FTP. 


O DNS é particularmente importante para o serviço de correio eletrônico. O registro MX 
identifica o servidor de correio eletrônico que manipula as mensagens de um determinado 
nome de domínio, indicando onde os usuários daquele domínio recebem suas mensagens. 
Cada domínio pode possuir diversos registros MX, que são usados em uma ordem de prefe- 


rência, indicada por um número inteiro positivo. 


O registro NS é utilizado para indicar o servidor de nomes de um dominio ou subdominio. 
Um servidor de nomes que faça a delegação de um subdominio utiliza o registro NS para 


indicar o servidor de nomes responsável pelo subdomínio. 


Servidor de nomes 





o Processo de aplicação que provê os diferentes tipos de mapeamento. 


a Servidores estão geograficamente distribuídos e cooperativamente realizam 


a resolução de nomes. 


a O servidor de um domínio mantém informações locais sobre os seus subdomínios 


e estações. 
o Oservidor de um domínio conhece todos os servidores de seus subdomínios imediatos. 


ao Servidores formam uma árvore hierárquica, correspondendo ao espaço de 





nomes hierárquico. 


Servidor de nomes (name server) é um termo também utilizado para identificar a estação que 
executa o processo servidor de nomes. Além de definir as regras para sintaxe de nomes e dele- 
gação de autoridade, o DNS especifica um serviço de resolução de nomes distribuído baseado 
no modelo cliente-servidor. O serviço DNS é composto por um conjunto de servidores de nomes 


que estão geograficamente distribuídos e realizam a resolução de nomes de forma cooperativa. 
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Um servidor de nomes é um processo de aplicação que provê diferentes tipos de mape- 
amento. Uma vez que a autoridade de uma zona é delegada, a entidade responsável pela 
zona deve definir vários servidores de nomes para a zona, provendo um mecanismo de 
tolerância a falhas. 


O servidor de nomes de um determinado domínio mantém informações locais sobre os seus 
subdomínios e estações, conhecendo todos os servidores de nomes dos seus subdomínios 
imediatamente inferiores. Assim, os servidores do domínio raiz conhecem todos os servi- 
dores dos domínios de nível mais alto, que, por sua vez, conhecem os servidores dos seus 
subdomínios, e assim por diante. Portanto, os servidores de nomes formam uma árvore 
hierárquica, correspondendo ao espaço de nomes hierárquico. 


Cliente (Resolver) 


a Processo de aplicação que acessa um ou mais servidores de nomes. s 
o Implementado em bibliotecas de função. 


a Torna-se parte do código da aplicação. 


Um cliente é qualquer processo de aplicação que acessa um ou mais servidores de nomes. 
O cliente é denominado resolver. Em sistemas Unix, o resolver é implementado e acessado 
através de bibliotecas de funções, incluídas no código da aplicação no processo de compi- 
lação ou carregadas dinamicamente em tempo de execução. Desta forma, o resolver torna- 
-se parte do código da aplicação. 


O resolver envia requisições de mapeamento a um ou mais servidores de nomes para, por 
exemplo, obter o endereço IP de uma estação a partir do seu respectivo nome ou identificar 
o servidor de correio eletrônico de um dado domínio. 


Servidor Bind 


Bind é a implementação mais adotada em sistemas Unix. a 
a Servidor de nomes é denominado named. 


a Cliente é configurado no arquivo /etc/resolv.conf. 
nameserver 192.168.10.65 
nameserver 150.10.1.1 


domain rnp.br 


Em sistemas Unix, a implementação DNS mais adotada é denominada Berkeley Internet 
Name Domain (BIND), cujo servidor é denominado named. Em sistemas Linux, o arquivo 
/etc/resolv.conf indica como o resolver deve se comportar. A primitiva nameserver indica o 
endereço IP do servidor de nomes que deve ser acessado. Até três primitivas nameserver 
podem ser incluídas, indicando diferentes servidores de nomes que podem ser acessados 
em caso de falha. A primitiva domain especifica o domínio default que é automaticamente 
acrescentado a qualquer nome incompleto, ou seja, não termina com um ponto. 

Por exemplo, se o usuário informa apenas o nome www, o resolver acrescenta o sufixo rnp.br, 
e, em seguida, requisita ao servidor de nomes a resolução do nome absoluto www.rnp.br. 


Servidor primário e secundário 





a Servidor primário (servidor mestre) 


m Mantém arquivos de configuração local com informações da zona em que 
possui autoridade. 


m Arquivos de configuração são criados e mantidos pelo administrador. a 


a Servidor secundário (servidor escravo) 
m Mantém uma cópia das informações das zonas em que possui autoridade. 
m Informações são diretamente obtidas do servidor primário (transferência de zona) 


m Cada zona deve possuir um único servidor primário e, preferencialmente, um ou 
mais servidores secundários. 


a Devem ser independentes. 
a Devem estar localizados em diferentes segmentos físicos ou instituições. 


o Um determinado servidor pode ser primário ou secundário de diversas zonas. 


Existem dois tipos de servidores de nomes: primário e secundário. O servidor primário, 
também denominado servidor mestre, mantém as informações sobre a zona sobre a qual 
possui autoridade em arquivos de configuração local. Estes arquivos de configuração são 
criados e mantidos pelo administrador do domínio. O servidor secundário, também deno- 
minado servidor escravo, apenas mantém uma cópia das informações da zona sobre a qual 


possui autoridade. Estas informações são obtidas diretamente do servidor primário. 


Após qualquer modificação nos arquivos de configuração da zona, o administrador deve 
solicitar que o servidor primário releia os arquivos de configuração. Em seguida, o servidor 
primário envia notificações de atualização aos servidores secundários. Além disso, periodi- 
camente, em intervalos configurados pelo administrador, o servidor secundário consulta o 
servidor primário para verificar se ocorreu alguma atualização nas informações da zona. 

O processo de transferência das informações do servidor primário para o servidor secun- 
dário é denominado transferência de zona (zone transfer). Na operação de transferência de 


zona, os servidores de nomes envolvidos adotam a porta TCP 53. 


Existe um único servidor primário para cada zona. No entanto, um determinado servidor 
de nomes pode ser o servidor primário ou secundário de diversas zonas. O administrador 
responsável pelo gerenciamento de uma zona deve configurar um servidor primário e, 
preferencialmente, um ou mais servidores secundários. Uma determinada zona pode não 
possuir servidores secundários. No entanto, para tornar o sistema menos susceptível a 
falhas, o administrador deve configurar pelo menos um servidor secundário. 


Os servidores primário e secundário devem ser independentes e estarem localizados em dife- 
rentes segmentos físicos da inter-rede ou, preferencialmente, em diferentes instituições, de 
modo que a disponibilidade do serviço de nomes para a zona não é afetada por uma falha em 
um destes servidores, ou mesmo por uma falha na conexão da instituição com a internet. 


Requisições iterativa e recursiva 


o Iterativa 
a Servidor utiliza apenas suas informações locais para resolver a requisição. 


m Resposta contém informações auxiliares que identificam os servidores com autori- 
dade no domínio de nível mais inferior. 


o Recursiva 


m Servidor utiliza suas informações locais e, caso necessário, envia requisições a 
outros servidores para resolver a requisição. 


m Resposta contém as informações requisitadas. 
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Existem dois tipos de requisições: iterativa e recursiva. Em uma requisição iterativa, também 
denominada não recursiva, o servidor de nomes utiliza apenas suas informações locais para 
resolver a requisição. Se o servidor de nomes possui as informações solicitadas, ele retorna 
estas informações para o cliente. Caso contrário, retorna apenas informações auxiliares que 
permitem ao cliente prosseguir no processo de resolução da requisição. Geralmente, estas 
informações auxiliares identificam os servidores de nomes com autoridade no domínio de 


nível mais inferior, que devem ser contatados para resolver a requisição. 


Por exemplo, quando um servidor de nomes com autoridade no domínio ufpb.br recebe 
uma requisição iterativa para resolver o nome www.di.ufpb.br, ele retorna uma resposta 
que apenas identifica os servidores de nomes com autoridade no domínio di.ufpb.br. Desta 
forma, a entidade requisitante pode contatar um destes servidores de nomes do domínio 


di.ufpb.br para resolver o nome www.di.ufpb.br. 


Por outro lado, em uma requisição recursiva, o servidor de nomes utiliza suas informações 
locais e, caso necessário, envia requisições iterativas para outros servidores de nomes para 
resolver o nome requisitado pelo cliente. Observe que, ao receber uma requisição recursiva, 
o servidor de nomes requisitado torna-se um cliente de outros servidores de nomes. Após 
resolver o nome requisitado, o servidor de nomes, que foi inicialmente requisitado, retorna 
a informação solicitada na requisição do cliente. Desta forma, uma requisição recursiva 


define um processo distribuído de resolução de requisições, que será detalhado adiante. 
Geralmente, a maioria dos servidores suporta requisições recursivas. No entanto, os 


Q servidores do domínio raiz, também denominados servidores raiz, suportam apenas 
requisições iterativas. 


Tipos de servidores 





ao Autoritativo 
m Responde autoritativamente por um domínio. 


o Recursivo 


m Recebe requisições recursivas e envia requisições iterativas para descobrir a resposta. 


o Forwarder 
m Recebe requisições recursivas e as repassa para um servidor recursivo. 


Um servidor de nomes pode ser classificado também de acordo com o tipo de requisição 
que é capaz de atender. Um servidor de nomes que é autoridade de um ou mais domínios, 

e que responde a requisições sobre este(s) dominio(s), é chamado de autoritativo. Já um 
servidor de nomes que recebe requisições recursivas, usualmente originadas de estações de 


trabalho, e utiliza requisições iterativas para obter a resposta, é chamado de recursivo. 


Na prática, um servidor de nomes pode ser autoritativo e recursivo ao mesmo tempo. 

No entanto, os servidores do domínio raiz são apenas autoritativos e suportam apenas 
requisições iterativas. Um terceiro tipo de servidor de nomes é o forwarder. Usualmente 
encontrado em roteadores ADSL/wireless, esse tipo de servidor recebe requisições das esta- 
ções de trabalho e as repassa para um servidor recursivo. Após obter a resposta do servidor 
recursivo, ele a repassa à estação que o solicitou. 


Mecanismo de arma- 
zenamento temporário 
de informações, cujas 
entradas são automati- 
camente removidas após 
um intervalo de tempo. 


Tipos de respostas 


a Com autoridade 
m Gerada por servidores que possuem autoridade no domínio do nome resolvido. 
m Resposta é bastante confiável, mas pode estar incorreta. 
a Sem autoridade 
m Gerada por servidores que não possuem autoridade no domínio do nome resolvido. 
m Resposta não é tão confiável, pois as informações podem ter sido modificadas. 


Um servidor pode retornar dois tipos de respostas: com autoridade (authoritative) e sem 
autoridade (non-authoritative). A resposta com autoridade somente é gerada por um ser- 
vidor de nomes que possui autoridade sobre o domínio, ao qual pertence o nome que deve 


ser resolvido. Desta forma, a resposta com autoridade somente pode ser fornecida pelo 


servidor primário ou pelos servidores secundários do domínio. Neste caso, a resposta retor- 
nada é bastante confiável. No entanto, eventualmente, se um servidor secundário ainda não 


está sincronizado com o servidor primário, existe a possibilidade da resposta fornecida por 


um servidor secundário ser incorreta. 


A resposta sem autoridade é gerada por um servidor de nomes que não possui autoridade 


sobre o domínio, ao qual o nome que deve ser resolvido pertence. A resposta sem autori- 


dade é fornecida por servidores de nomes que mantêm em cache local as informações sobre 


o nome que deve ser resolvido. Neste caso, a resposta retornada não é tão confiável, pois as 


informações do domínio podem ter sido modificadas. 


Mecanismo de cache 


ao Cada servidor mantém uma cache de resolução de nomes. a 


a Cache armazena todas as respostas mais recentes. 
m Reduz o tráfego DNS. 
a Torna eficiente a resolução de nomes. 
a Resposta fornecida a partir da cache é sem autoridade. 
a Resposta indica os servidores com autoridade no respectivo dominio. 
a Cada entrada da cache possui um tempo de vida (Time to Live). 


m Tempo de vida de cada entrada é configurado pela entidade com autoridade no 


respectivo domínio. 
a Cada resposta sinaliza seu tempo de vida na cache. 
o Entrada é automaticamente removida da cache quando o seu tempo de vida expira. 


Para reduzir o tráfego DNS na internet, os servidores de nomes adotam um mecanismo 
de cache. Cada servidor mantém uma cache de resolução de nomes que armazena todas 


as respostas associadas aos nomes que foram recentemente resolvidos. Sempre que um 
servidor de nomes resolve um determinado nome, ele mantém as respectivas informações 
em memória. Desta forma, novas requisições para aquele mesmo nome podem usar as 
informações em cache. Este mecanismo reduz o tráfego DNS na internet, pois consultas 


adicionais a outros servidores de nomes não são necessárias. 


Para cada nome resolvido, a cache mantém as próprias informações associadas ao nome. 
Além disso, a cache também armazena informações sobre a origem das respectivas res- 


postas. Quando um cliente solicita a resolução de um dado nome, primeiramente, o servidor 
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de nomes verifica se tem autoridade para aquele nome. Em caso afirmativo, ele retorna uma 
resposta com autoridade. Caso contrário, o servidor de nomes verifica se a cache possui o 
mapeamento requisitado pelo cliente. Caso afirmativo, o servidor de nomes retorna uma 
resposta sem autoridade, que também inclui a lista de servidores com autoridade para 


aquele domínio. 


O mecanismo de cache é bastante eficiente no DNS porque os registros de recursos de um 
determinado domínio não mudam frequentemente. No entanto, se as informações na cache 
são mantidas indefinidamente, existe uma razoável probabilidade destas informações se 
tornarem incorretas, pois as informações de um domínio podem ser modificadas pela enti- 
dade com autoridade. 


Para manter a consistência das informações na cache, os servidores de nomes associam um 
tempo de vida (Time to Live) a cada entrada da cache. Após expirar este intervalo de tempo, 
a entrada é automaticamente removida da cache. Os tempos de vida não são idênticos para 
todas as entradas da cache. 


O tempo de vida de cada entrada é configurado pela entidade com autoridade no respectivo 
domínio, pois esta entidade possui condições de indicar o tempo de validade das informa- 
ções. Nas respostas, os servidores de nomes informam o tempo de vida da resposta, especi- 
ficando o número de segundos que a entrada pode permanecer na cache. 


Processamento de requisições 


ao Processo distribuído de resolução de requisições. 
a Servidores de nomes usam arquivos de configuração. 


a Exemplo de processamento de requisições DNS. 


Como já sabemos, o DNS adota um processo distribuído de resolução de requisições. Para 
assegurar a correta resolução de requisições, todo cliente (resolver) deve conhecer um ou 
mais servidores de nomes. No entanto, os servidores de nomes não conhecem todos os 
outros servidores. Todo servidor de nomes conhece os endereços dos servidores raiz. Além 
disso, um servidor de nomes de um determinado domínio conhece os servidores de nomes 
de todos os seus subdomínios de nível imediatamente inferior. Estas informações são inclu- 


ídas nos arquivos de configuração dos servidores de nomes. 


A figura 10.2 ilustra um exemplo completo do processamento de uma requisição, no qual as 
requisições e respostas são mostradas usando a sintaxe do comando tcpdump. 


a.root-servers.net 


2A? www.rnp.br 


a 

a 2- 0/5/5 

QU 

© 

5 

g 1+ A? www.rnp.br 3A? www.rnp.br 

pu SED Name SSS 

Gi .dns.b 

E Resolver | «= | server — ae 

E 12/4/0 3- 0/4/4 

© 

à 

o 4A? www.rnp.br Figura 10.2 

E lua.na-df.rnp.br Processamento de 
2 4*- 2/4/4 requisições DNS. 
< 
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Inicialmente, o cliente (resolver) envia uma requisição recursiva para o servidor de nomes 
local (name server), solicitando o endereço IP (A?) associado ao nome www.rnp.br. Nesta 


requisição, o termo 1+ identifica o número da requisição (1) e indica que ela é recursiva (+). 


Após receber a requisição recursiva, o servidor de nomes local verifica se já existe uma 
entrada na cache com este mapeamento. Caso afirmativo, o servidor local retorna uma res- 
posta sem autoridade para o cliente. 


No entanto, vamos considerar que o servidor local não possui esta informação em cache. 
Neste caso, o servidor local envia uma requisição iterativa para um servidor raiz 
(a.root-servers.net), também solicitando o endereço IP (A?) associado ao nome www.rnp.br. 


Nesta requisição, o termo 2 identifica o número da requisição. A ausência do termo + indica 


que a requisição é iterativa. 


Ao receber a requisição iterativa 2, o servidor raiz a.root-servers.net retorna uma resposta 
que contém os nomes e os respectivos endereços IP dos servidores de nomes do domínio 
br. Nesta resposta, o termo 2- identifica o número da resposta (2) e indica que o servidor 
raiz não suporta requisições recursivas (-). O termo 0/5/5 indica que a resposta não 
contém o endereço IP requisitado (0), mas contém cinco registros de autoridade (5) e cinco 
registros auxiliares (5). Os registros de autoridade identificam os nomes dos cinco servi- 
dores com autoridade no domínio br. Em complemento, os registros auxiliares identificam 


os endereços IP destes cinco servidores. 


Neste ponto, o servidor de nomes local envia uma nova requisição iterativa para um dos servi- 
dores do dominio br, também solicitando o endereço IP (A?) associado ao nome www.rnp.br. 
Neste exemplo, estamos assumindo que o servidor local envia a requisição ao servidor 
a.dns.br. Nesta requisição, o termo 3 identifica o número da requisição. Novamente, a 


ausência do termo + indica que a requisição é iterativa. 


Ao receber a requisição iterativa 3, o servidor a.dns.br retorna uma resposta que contém 

os nomes e os respectivos endereços IP dos servidores de nomes do domínio rnp.br. Nesta 
resposta, o termo 3- identifica o número da resposta (3) e indica que o servidor a.dns.br 
também não suporta requisições recursivas (-). O termo 0/4/4 indica que a resposta não 
contém o endereço IP da estação www.rnp.br (0), mas contém quatro registros de autori- 
dade (4) e quatro registros auxiliares (4). Os registros de autoridade identificam os nomes 
dos quatro servidores com autoridade no domínio rnp.br. Além disso, os registros auxiliares 


identificam os endereços IP destes quatro servidores. 


Conhecendo os endereços dos servidores do domínio rnp.br, o servidor de nomes local 
envia uma nova requisição iterativa para um dos servidores do domínio rnp.br, também 
solicitando o endereço IP (A?) associado ao nome www.rnp.br. Neste exemplo, estamos 


assumindo que o servidor local envia a requisição iterativa 4 ao servidor /ua.na-df.rnp.br. 


Ao receber a requisição iterativa 4, o servidor lua.na-df.rnp.br retorna uma resposta com 


autoridade (*) que contém os endereços IP da estação www.rnp.br. O termo 2/4/4 indica que 


a resposta contém dois registros de resposta (2), quatro registros de autoridade (4) e quatro 
registros auxiliares (4). Os dois registros de resposta contêm os endereços IP da estação 


www.rnp.br. Em complemento, os registros de autoridade e auxiliares sinalizam os nomes e 


os endereços IP dos servidores com autoridade no domínio rnp.br. 


Após obter os endereços IP da estação www.rnp.br, o servidor local armazena esta infor- 


mação na cache, e, em seguida, retorna para o cliente a resposta sem autoridade que 


contém os endereços IP da estação www.rnp.br, também indicando os nomes dos quatro 


servidores com autoridade no domínio rnp.br. 
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Como pode ser observado no exemplo, o servidor de nomes local envia requisições aos 
servidores de todos os domínios superiores. No entanto, na maioria dos casos, não é neces- 
sário enviar requisições aos servidores de todos os domínios superiores, pois é bastante 
comum um servidor de nomes ter autoridade sobre diversos domínios. Por exemplo, um 
único servidor de nomes pode conter informações sobre os domínios br e rnp.br, eliminando 


assim uma ou mais consultas remotas. 


Além disso, considerando que o servidor de nomes local mantém uma cache com as infor- 
mações das respostas mais recentes, existe uma razoável probabilidade das requisições 
serem resolvidas localmente com as informações da cache. 


SMTP 


Simple Mail Transfer Protocol (SMTP) implementa o serviço de correio eletrônico da 
arquitetura TCP/IP. | 


O serviço de correio eletrônico é uma das aplicações mais populares na internet. O serviço 
de correio é padronizado nos RFCs 821 e 822, que especificam o protocolo Simple Mail 
Transfer Protocol (SMTP) e o formato das mensagens. 


Componentes 


o Agente usuário 
m Programa usado pelo usuário para ler, compor e enviar mensagens. 
m Usado pelo usuário remetente e destinatário. 


a Também denominado leitor de correio. 


o Servidor de correio 


m Realiza o roteamento de mensagens. 
m Configurado pelo administrador de domínio. 


m Também denominado agente de transferência de mensagens. 


a Caixa de mensagens (mailbox) 


m Mantém as mensagens enviadas aos respectivos usuários. 
m Cada usuário possui uma caixa de mensagens. 


a Viabiliza o modelo de comunicação assíncrona. 


o Filade mensagens 


m Armazena temporariamente as mensagens até que seja possível entregá-las. 


m Adota a técnica de spooling para tratar falhas temporárias nos servidores de correio. 


Remetente Destinatário 


Fila de Fila de 


mensagens mensagens 





Agente Servidor de ) SMTP » | Servidor de Agente 
usuário correio correio usuário 





Caixa de Caixa de 


mensagens mensagens 











Figura 10.3 
Serviço de correio 
eletrônico (SMTP). 


Como mostrado na figura 10.3, o serviço de correio eletrônico envolve dois tipos de compo- 
nentes: o agente usuário e o servidor de correio. O agente usuário (UA - User Agent), comu- 
mente denominado leitor de correio, é o programa usado pelo usuário para ler, compor e 
enviar mensagens. Assim, o agente é utilizado, tanto pelo usuário remetente, quanto pelo 
usuário destinatário. Como exemplos de agentes, podemos citar: pine, elm, Thunderbird e 


Microsoft Outlook. Os usuários escolhem o agente mais adequado às suas necessidades. 


O servidor de correio, também denominado Agente de Transferência de Mensagens 

(MTA - Message Transfer Agent), é responsável pelo roteamento de mensagens na internet. 
O servidor de correio mais usado em sistemas Linux é o sendmail. Os usuários não usam 
diretamente o servidor de correio. É responsabilidade do administrador configurar o ser- 


vidor de correio de um determinado domínio. 


O serviço de correio eletrônico suporta um modelo de comunicação assíncrona, que não 
requer que o usuário esteja conectado para que mensagens possam ser enviadas para 

ele. Para tal, no servidor de correio de um determinado domínio, cada usuário do domínio 
possui uma caixa de mensagens (mailbox), também denominada caixa postal. A caixa de 
mensagens de um determinado usuário mantém as mensagens enviadas ao usuário. Além 
disso, o serviço de correio eletrônico adota a técnica de spooling para tratar de falhas tempo- 
rárias nos servidores. Nesta técnica, cada servidor mantém uma fila de mensagens (spool), 


que armazena temporariamente as mensagens até que seja possível entregá-las. 


Protocolo SMTP 


ao Protocolo de aplicação do serviço de correio eletrônico da arquitetura TCP/IP. a 

ao Define um conjunto de comandos e respostas. 

a Especificado no RFC 821. 

a Utiliza a porta TCP 25. 

a Adotado para transportar as mensagens nos seguintes estágios: 
m Agente e servidor de correio do usuário remetente. 


m Servidores de correio dos usuários remetente e destinatário. 





O SMTP é o protocolo de aplicação do serviço de correio eletrônico. O SMTP utiliza a porta 
TCP 25. O SMTP define como as mensagens são enviadas. Na maioria dos casos, como 
mostra a figura 10.3, o envio de uma mensagem envolve os agentes do usuário remetente e 


do destinatário, como também seus respectivos servidores de correio. 


Envio de mensagem 


ao Agente do usuário remetente envia a mensagem para o servidor do remetente. a 
a Servidor do remetente armazena a mensagem na fila. 
a Servidor do remetente envia a mensagem para o servidor do destinatário. 


m Consulta o DNS, solicitando os registros MX associados ao dominio do usuário 


destinatário. 


a Em caso de falha, servidor do remetente mantém a mensagem na fila e tenta reenviar. 





a Servidor do destinatário armazena a mensagem na respectiva caixa de mensagens. 


Quando o usuário solicita o envio de uma mensagem, inicialmente, usando o protocolo 


SMTP, o agente do usuário remetente envia a mensagem ao servidor de correio do usuário 
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remetente. Após receber a mensagem, o servidor do usuário remetente armazena a men- 
sagem na fila, e, imediatamente, tenta entregá-la ao servidor do usuário destinatário. Para 
entregar a mensagem, primeiramente, o servidor do usuário remetente deve descobrir o 
servidor do usuário destinatário. Para isso, o servidor do usuário remetente consulta o serviço 
de nomes (DNS), solicitando os registros MX associados ao domínio do usuário destinatário. 


Por exemplo, se o endereço do usuário destinatário é gledson@di.ufpb.br, o servidor do 
usuário remetente solicita ao serviço de nomes os registros MX associados ao domínio 
di.ufpb.br. Caso existam diversos registros MX, o registro que possui o menor valor de 
preferência é selecionado. Após descobrir o endereço do servidor do usuário destinatário, 
usando o protocolo SMTP, o servidor do usuário remetente envia a mensagem para o ser- 
vidor do usuário destinatário. 


Se não é possível realizar a entrega a algum servidor do usuário destinatário, o servidor do 
usuário remetente mantém a mensagem na fila e tenta enviar posteriormente em intervalos 
configurados pelo administrador. A especificação recomenda um tempo de espera de 

30 minutos entre cada tentativa e um tempo de espera total de 4 ou 5 dias. Se a mensagem 
não é entregue dentro do tempo de espera total, que também pode ser configurado pelo 
administrador, o servidor do usuário remetente remove a mensagem da fila e notifica o 


usuário remetente enviando uma mensagem para a sua caixa de correio. 


Ao receber a mensagem, o servidor do usuário destinatário armazena a mensagem na caixa 
de mensagens do usuário. Por fim, quando o usuário destinatário deseja ler a mensagem, 


usando um agente usuário, ele acessa a mensagem armazenada em sua caixa de mensagens. 


Leitura de mensagem 





Agente do usuário recupera mensagens da caixa de mensagens do servidor de correio 
do usuário. 


o Acesso direto 


a Agente usuário executa na mesma estação em que reside o arquivo que contém a 
caixa de mensagens do usuário. 


a Acesso via protocolo de acesso 


m Agente usuário pode executar em estação diferente daquela em que reside o 


arquivo que contém a caixa de mensagens do usuário. 


m Adota os protocolos POP3 ou IMAP. 


O agente usuário pode acessar a caixa de mensagens diretamente ou através de um 
protocolo de acesso. No primeiro caso, o agente usuário executa na estação onde reside o 
arquivo que contém a caixa de mensagens e, portanto, pode acessá-lo diretamente. 

No segundo caso, o agente usuário pode residir em uma estação remota, diferente daquela 
que armazena a caixa de mensagens do usuário. Neste caso, o agente usuário adota o proto- 


colo POP3 ou IMAP para recuperar o conteúdo da caixa de mensagens. 
Comandos do protocolo 


O protocolo SMTP define um conjunto de comandos e respostas. Os comandos são enviados 
pelo cliente para o servidor. As respostas são enviadas do servidor para o cliente. O servidor 
deve enviar uma resposta para cada comando enviado pelo cliente. Cada resposta possui 
um código numérico, que sinaliza o correto processamento do comando ou indica um deter- 
minado tipo de erro. Opcionalmente, a resposta possui um pequeno texto associado, que 
descreve o significado da resposta. 


Principais comandos do protocolo: 


ao HELO - identifica o cliente ao servidor. 

a MAIL -indica o remetente da mensagem. 

a RCPT -informa o destinatário da mensagem. 

a DATA - envia o conteúdo da mensagem. 

a QUIT -finaliza a sessão. 

a TURN -inverte a direção de envio. 

a RSET - aborta a transação de correio. 

o VRFY -verifica a validade de um usuário. 

o EXPN - identifica a composição de uma lista. 

Vale ressaltar que, na comunicação entre o agente e o servidor do usuário remetente, os 
papéis de cliente e servidor são desempenhados pelo agente e servidor de correio, respec- 
tivamente. Além disso, na comunicação entre o servidor do usuário remetente e o servidor 


do usuário destinatário, os papéis de cliente e servidor são desempenhados pelo servidor 


remetente e servidor destinatário, respectivamente. 


Modelo de interação 


Em geral, a interação cliente-servidor é realizada usando cinco comandos. A listagem a 
seguir apresenta um exemplo de envio de mensagem, onde os principais comandos e res- 


postas do protocolo podem ser identificados. 


Inicialmente, o cliente estabelece uma conexão na porta TCP 25 do servidor. Imediatamente 
após o estabelecimento da conexão, o servidor envia a resposta de saudação 220, que sina- 
liza que o mesmo está pronto para iniciar uma transação. A resposta de saudação identifica 
o nome absoluto do servidor. Neste exemplo, o servidor é mail.rnp.br. 


Em seguida, o cliente identifica-se enviando o comando HELO, que contém o seu nome abso- 
luto. Neste exemplo, o cliente é mail.di.ufpb.br. Após receber o comando HELO, se o servidor 
aceita a identificação do cliente, ele retorna a resposta 250, que contém os nomes absolutos 


do servidor e do cliente. Caso contrário, o servidor retorna uma resposta de erro 501. 


250 Message accepted for delivery 
QUIT 
221 mail.rnp.br closing connection 


Sa 220 mail. rnpdr 

C: HELO mail.di.ufpb.br 

S: 250 mail.rnp.br Hello mail.di.ufpb.br, pleased to meet you 
C: MAIL From: gledson@di.ufpb.br 

S: 250 <gledson@di.ufpb.br>... Sender ok 

C: RCPT To:ari@rnp.br 

S: 250 <ari@rnp.br>... Recipient ok 

C: DATA 

S: 354 Enter mail, end with “.” on a line by itself 
CRESTE 

(Ge 

SE 

G: 

SE 


Após a identificação das estações cliente e servidor, o cliente envia o comando MAIL para 
indicar o início de uma transação. Neste comando, o cliente identifica o endereço de correio 
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eletrônico do usuário remetente da mensagem. No exemplo acima, o usuário remetente 

é gledson@di.ufpb.br. Após receber o comando MAIL, se o servidor aceita o endereço do 
usuário remetente, ele envia a resposta de aceitação 250. Caso contrário, o servidor retorna 
uma resposta de erro 501. 


Iniciada a transação, o cliente envia o comando RCPT, que identifica o endereço de correio 
eletrônico do usuário destinatário da mensagem. No exemplo acima, o usuário destinatário 
é ari@rnp.br. Após receber o comando RCPT, se o servidor aceita o endereço do usuário 
destinatário, ele envia a resposta de aceitação 250. Caso contrário, o servidor retorna a 
resposta de erro 550. 


Para uma mensagem com múltiplos destinatários, o cliente deve enviar diversos comandos RCPT, 
cada um deles identificando um diferente usuário destinatário. Neste caso, para cada comando 


RCPT enviado pelo cliente, o servidor deve retornar uma resposta de aceitação ou erro. 


Após indicar o remetente e os destinatários, o cliente envia o comando DATA, informando 
que deseja iniciar a transferência do conteúdo da mensagem. Após receber o comando 
DATA, o servidor envia a resposta 354, confirmando que está pronto para receber o con- 
teúdo da mensagem. Em seguida, o cliente envia o conteúdo da mensagem. Para sinalizar 
o fim da mensagem, o cliente envia uma linha contendo apenas a sequência de bytes 
<CR><LF>.<CR><LF>, onde <CR> e <LF> representam os caracteres de retorno do cursor 


(Carriage Return) e mudança de linha (Line Feed), respectivamente. 


Após detectar o fim da mensagem, o servidor retorna a resposta de aceitação 250. Neste 
momento, a mensagem já está armazenada na fila do servidor. Desta forma, o cliente pode 
fechar a sessão usando o comando QUIT. O servidor confirma o fechamento da sessão enviando 


a resposta 221, que indica que a mensagem está sendo encaminhada ao usuário destinatário. 


Se o cliente possui várias mensagens para o mesmo servidor, ele pode enviar todas as men- 
sagens na mesma sessão. Para tal, ao concluir o envio de uma mensagem, ao invés de usar 
o comando QUIT, o cliente inicia uma nova transação com um novo comando MAIL. Neste 


caso, o comando QUIT somente será usado após o envio de todas as mensagens. 


Consequentemente, em uma única sessão de troca de mensagens, podem existir diversas 
transações. Cada transação consiste de um comando MAIL, um ou vários comandos RCPT, e 
um comando DATA. Por fim, a sessão é fechada com o comando QUIT. 


Antes de fechar uma sessão, opcionalmente, o cliente pode enviar o comando TURN, solici- 
tando a troca de papéis entre o cliente e o servidor. O comando TURN permite que mensa- 
gens sejam enviadas na direção inversa. Ao receber o comando TURN, se o servidor aceita 

a troca de papéis, ele envia a resposta de aceitação 250. Caso contrário, o servidor envia a 

resposta de rejeição 502. 


Embora os comandos apresentados sejam os mais utilizados, o protocolo SMTP define outros 
comandos. Por exemplo, a qualquer momento, uma transação pode ser abortada com o 


comando RSET, fazendo com que qualquer informação armazenada no servidor seja descartada. 


O comando VRFY permite ao cliente verificar se um determinado usuário é válido no ser- 


vidor. O comando EXPN expande uma lista de distribuição, identificando os membros da Lista de distribuição 


lista. Geralmente, estes comandos são usados pelos administradores para depurar pro- Grupo de usuários com 
algum interesse comum 
que se organizam para 
trocar mensagens 
através do serviço de 
correio eletrônico. 


blemas no serviço de correio eletrônico. Por questão de segurança e privacidade, muitos 
administradores desabilitam os comandos VRFY e EXPN. 


Multipurpose Internet 
Mail Extensions é a 
extensão do serviço de 
correio eletrônico que 
permite estruturar o 
corpo da mensagem 
em múltiplas partes 

e viabilizar o envio de 
mensagens que trans- 
portam dados binários 
arbitrários. 


Estrutura da mensagem 


o Envelope 

a Contém os endereços dos usuários remetente e destinatário. 
a Cabeçalho 

m Descreve características das mensagens (From, To, Subject). 
o Corpo 

m Conteúdo da mensagem. 


m Contém apenas caracteres ASCII de 7 bits. 





m MIME permite mensagens com múltiplas partes e diferentes formatos. 


As mensagens são compostas por três partes, cada uma com sua função própria: 


o O envelope é usado pelo servidor de correio para realizar a entrega da mensagem. 


O envelope contém o endereço do remetente e o endereço do destinatário. 


a O cabeçalho contém diversas entradas. Cada entrada possui um nome, seguido pelo 
símbolo dois pontos (:) e o valor do campo. As entradas do cabeçalho descrevem algumas 
características da mensagem, como por exemplo: o endereço do usuário remetente 
(From), o endereço do usuário destinatário (To) e o assunto da mensagem (Subject). 


a O corpo é o conteúdo propriamente dito da mensagem e deve conter apenas caracteres 
ASCII de 7 bits. 


O agente usuário adiciona o cabeçalho ao corpo da mensagem e envia o resultado para 
o servidor do usuário remetente. Por sua vez, o servidor do usuário remetente adiciona 
algumas entradas no cabeçalho e envia o resultado ao servidor do usuário destinatário. Por 
fim, o servidor do usuário destinatário adiciona algumas entradas no cabeçalho e armazena 


a mensagem na caixa de mensagens do usuário destinatário. 


Como originalmente especificado, o serviço de correio eletrônico somente suporta mensa- 
gens ASCII de 7 bits. Para suportar mensagens que transportam dados binários arbitrários, 
a extensão MIME foi proposta nos RFCs 2045 e 2046. Esta extensão permite estruturar o 


corpo da mensagem em múltiplas partes. Vale ressaltar que, independente do conteúdo da 
mensagem, o cabeçalho e o corpo de uma mensagem MIME continuam sendo transmitidos 


com apenas caracteres ASCII de 7 bits. 


Para transportar dados binários arbitrários, a extensão MIME define mecanismos que codi- 
ficam dados binários para caracteres ASCII de 7 bits. Para tal, um agente MIME remetente 
adiciona algumas entradas no cabeçalho e no corpo da mensagem que indicam ao agente 
MIME destinatário a estrutura e a codificação da mensagem. Desta forma, a extensão MIME 
não impõe qualquer modificação nos servidores de correio, pois apenas os agentes devem 


interpretar a extensão MIME. 


HTTP 


o Hypertext Transfer Protocol (HTTP) 
= Implementa o serviço web. 
m Permite aos provedores de conteúdo a publicação de documentos. 


m Permite aos usuários a recuperação, visualização e navegação nos documentos. 
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o Cliente web (browser) 

a Permite a recuperação, visualização e navegação em documentos web. 

m Mantém uma cache que armazena os documentos recentemente recuperados. 
a Servidor web 

= Permite a publicação de documentos. 


m Gerencia um repositório de documentos que contém os objetos publicados. 


O serviço web, formalmente denominado World Wide Web (WWW), é a aplicação mais 
usada na internet. Ele é suportado pelo protocolo Hypertext Transfer Protocol (HTTP), cuja 
versão 1.1 é especificada no RFC 2616. O serviço web permite aos provedores de conteúdo a 
publicação de documentos na internet. Por outro lado, o serviço web permite aos usuários a 
recuperação e a visualização de documentos, bem como a navegação na estrutura de hiper- 
texto definida pelos documentos. 


Um documento web, também conhecido como página web, é composto por diversos objetos 
com diferentes conteúdos e formatos. A estrutura hipertexto de um documento web é 
definida por um arquivo Hypertext Markup Language (HTML), que contém referências (links) 
aos demais objetos que compõem o documento. Em um documento web (arquivo HTML), 
cada referência representa um objeto que deve ser recuperado. Existem diversos tipos de 


objetos, por exemplo: arquivos HTML, imagens JPEG e GlF e applets Java. 


Cada objeto é identificado por um Universal Resource Locator (URL). Cada URL identifica o 
nome do servidor web que armazena o objeto e o nome do objeto no sistema de arquivos 
deste servidor. Por exemplo, o URL www.rnp.br/newsgen/index.html está armazenado no 





mentos deste servidor. 


Como mostra a figura 10.4, o serviço web envolve dois tipos de componentes: o cliente 
e o servidor. 


Cliente é gibis » Servidor 
Web Web 


Figura 10.4 
Características do 
HTTP. 





O cliente web, denominado navegador, é um processo de aplicação utilizado pelo usuário 
para recuperar e visualizar os documentos web, bem como navegar na estrutura de hiper- 
texto definida pelos vários documentos. Existem diversas implementações do cliente web, 


sendo as mais populares o Firefox, o Google Chrome e o Microsoft Internet Explorer. 


Por outro lado, o servidor web é um processo de aplicação que gerencia um repositório 

de documentos web, publicados pelos respectivos provedores de conteúdo. Além disso, o 
servidor web permite que os clientes web possam recuperar estes documentos. Também 
existem diversas implementações de servidores web, onde os mais adotados são o Apache 


e o Microsoft Internet Information Service. 


Por default, o servidor web aguarda requisições de conexão na porta TCP 80. No entanto, a 


porta adotada pode ser configurada pelo administrador do servidor. Neste caso, a nova porta 


deve ser explicitamente informada em todas as URLs que referenciam documentos arma- 


zenados neste servidor. O cliente web também assume, por default, que o servidor aguarda 


requisições na porta TCP 80. Desta forma, a porta 80 não precisa ser informada nas URLs. 


Protocolo HTTP 


O protocolo HTTP define os tipos e os formatos das mensagens trocadas entre os clientes 


Define um conjunto de mensagens de requisição e resposta. 
Especificado no RFC 2616. 

Adota a porta TCP 80. 

Requisição 

m (Composta por uma linha de requisição, linhas de cabeçalho e corpo. 
Resposta 


m Composta por uma linha de status, linhas de cabeçalho e corpo. 


e os servidores. Quando o usuário clica em uma determinada URL, solicitando um docu- 


a 





mento web, o cliente envia uma mensagem de requisição HTTP para o respectivo servidor, 


solicitando o objeto especificado na URL. Ao receber uma requisição, o servidor recupera o 


documento solicitado e retorna uma mensagem de resposta que contém este documento. 


Após recuperar um documento web, o cliente identifica cada objeto que compõe este 


documento base, e, em seguida, envia uma nova mensagem de requisição HTTP para 


recuperar cada um destes objetos. Para cada mensagem de requisição, o servidor retorna 


uma resposta que contém o objeto solicitado. O HTTP é um protocolo sem estado, pois os 


servidores web não armazenam qualquer informação sobre os clientes web. 


Tipos de conexões 


Conexão não persistente 

m Transporta uma única requisição e sua respectiva resposta. 
m Recupera um único objeto. 

m Servidor fecha a conexão após a resposta. 

Conexão persistente 


m Pode transportar diversas requisições e suas respectivas respostas. 


m Todos os objetos de um documento podem ser recuperados em uma única conexão. 


m Servidor fecha a conexão após um intervalo de inatividade. 

Conexão não persistente serial 

m Cliente estabelece uma conexão por vez e recupera um objeto em cada conexão. 
Conexão não persistente paralela 

m Cliente estabelece conexões simultâneas e recupera um objeto em cada conexão. 
Conexão persistente não paralela 

m Uma nova requisição é enviada somente após o recebimento da resposta anterior. 


Conexão persistente paralela 


a Diversas requisições podem ser enviadas antes do recebimento de qualquer resposta. 


a 
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O protocolo HTTP adota o conceito de conexões persistentes e conexões não persistentes. 
Vale ressaltar que a versão 1.0 do protocolo HTTP suporta apenas conexões não persistentes. 


Em uma conexão não persistente, o cliente estabelece a conexão com o servidor e envia a 
mensagem de requisição para recuperar um determinado objeto. No outro lado, o servidor 
processa a requisição, retorna a mensagem de resposta contendo o objeto solicitado, e, em 
seguida, imediatamente fecha a conexão. Desta forma, cada conexão não persistente trans- 
porta uma única mensagem de requisição e sua respectiva resposta. Consequentemente, uma 
conexão não persistente deve ser estabelecida para cada objeto requisitado pelo cliente. 


Dependendo da implementação do cliente web, para um determinado documento web com- 
posto por diversos objetos, as conexões não persistentes podem ser estabelecidas no modo 
serial ou paralelo. No modo serial, o cliente estabelece uma conexão por vez e recupera um 
objeto em cada conexão. No modo paralelo, o cliente estabelece diversas conexões simultâ- 
neas e recupera um objeto em cada conexão. Na prática, muitos clientes web permitem que os 
usuários configurem o número máximo de conexões paralelas que podem ser estabelecidas. 


Em uma conexão persistente, após enviar a resposta, o servidor mantém a conexão aberta, 
permitindo que requisições e respostas subsequentes possam ser enviadas na mesma conexão. 
Desta forma, o cliente pode solicitar diversos objetos, e o servidor devolver diversas respostas 
em uma única conexão. Consequentemente, um documento web e todos os seus objetos 
podem ser recuperados em uma única conexão. Geralmente, o servidor web fecha uma conexão 


persistente após um tempo de inatividade, que é configurável pelo administrador. 


Nas conexões persistentes, as requisições podem ser realizadas com ou sem paralelismo. 
No modo não paralelo, o cliente envia uma nova requisição somente após receber a res- 
posta da requisição anterior. No modo paralelo, o cliente envia diversas requisições antes de 
receber as respostas anteriores. Desta forma, todos os objetos que compõem um docu- 


mento podem ser requisitados, antes de receber qualquer um deles. 


As conexões persistentes melhoram o desempenho do serviço web, pois evitam o desperdício 
de tempo e recursos com o estabelecimento e fechamento de conexões individuais para cada 
objeto. No lado cliente, o desempenho do serviço web também é melhorado com a implemen- 
tação de um repositório local (cache) que armazena os documentos recentemente recupe- 
rados. O mecanismo de cache reduz os atrasos na recuperação de objetos e diminui o tráfego 
gerado na internet, pois documentos previamente armazenados no repositório local não 
precisam ser transmitidos novamente. Além disso, o mecanismo de cache permite ao usuário 
visualizar um conteúdo previamente armazenado, mesmo na ausência de conectividade. 


Modelo de interação 


o Protocolo HTTP 





= Requisição 
m GET: recupera o objeto informado na URL. 
a POST: envia informações de formulário. 

= Resposta 
a 200: requisição processada com sucesso. 
a 301: objeto solicitado foi movido. 
a 400: erro genérico no processamento. 
a 404: objeto solicitado não existe. 


a 505: versão requisitada não é suportada. 


O protocolo HTTP define dois tipos de mensagens: a requisição e a resposta. As mensagens 
de requisição e resposta adotam o formato ASCII, exceto no conteúdo dos objetos enviados. 
Desta forma, como nos protocolos SMTP e FTP, as requisições e as respostas HTTP podem 
ser facilmente lidas pelos usuários. No exemplo de interação entre o cliente e o servidor, 
mostrado na listagem a seguir, os principais elementos que compõem as requisições e as 


respostas podem ser identificados. 


C: GET /newsgen/index.html HTTP/1.1 
Host: www.rnp.br 
Connection: close 
User-Agent: Mozilla/4.0 
Accept-Language: sgn-BR 
<CR><LF> 

So HITTE- 200 OK 
Connection: close 
Date: Sun, 01 Aug 2004 15:00:00 GMT 
Server: Apache/1.3.0 (Unix) 
Last-Modified: Mon, 22 Jun 2004 10:04:17 GMT 
Content-Length: 1500 
Content-Type: text/html 
RED 


Inicialmente, o cliente estabelece uma conexão na porta TCP 80 do servidor. Em seguida, 

o cliente envia a mensagem de requisição, que é composta por uma linha de requisição, 
algumas linhas de cabeçalho e o corpo. A linha de requisição identifica o método a ser exe- 
cutado pelo servidor, o objeto a ser recuperado (URL) e a versão do protocolo HTTP. 

No exemplo o cliente está usando o método GET para solicitar o objeto /newsgen/index.html 


através do protocolo HTTP/1.1. 


O protocolo HTTP define alguns métodos; os mais usados são: GET e POST. O método GET é 
usado pelo cliente para solicitar a recuperação de um determinado objeto do servidor. 

A maioria das interações entre o cliente e o servidor adota o método GET. O método POST é 
semelhante ao método GET, mas envia informações adicionais para o servidor. Estas infor- 


mações adicionais são obtidas de formulários preenchidos pelos usuários. 


As linhas do cabeçalho possuem informações que auxiliam o servidor no tratamento da 
requisição. Cada linha de cabeçalho possui um nome e um valor associado. Existem diversos 
tipos de linhas de cabeçalho, o exemplo de interação acima apresenta apenas alguns tipos 


de linhas de cabeçalho. 


O cabeçalho Host especifica o servidor no qual o objeto solicitado está armazenado. O cabe- 
çalho Connection indica se o servidor deve ou não fechar a conexão após enviar o objeto. 
Neste exemplo, após enviar o objeto, o servidor deve fechar a conexão (close). O cabeçalho 
User-Agent sinaliza o tipo de cliente que está gerando a requisição. Neste exemplo, o cliente 
é o Mozilla/4.0. Esta linha permite que o servidor possa enviar diferentes versões do mesmo 
objeto, dependendo do tipo de cliente. Por fim, o cabeçalho Accept-Language indica o idioma 
de preferência do usuário. Se o objeto solicitado não existe naquele idioma, o servidor envia 


o objeto no idioma default. 


Na mensagem de requisição, após as linhas de cabeçalho, existe o corpo da mensagem. 
O método GET não usa o corpo da mensagem. Por outro lado, no método POST, o corpo da 


requisição contém as informações do formulário que foi preenchido pelo usuário. 
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As linhas do cabeçalho e o corpo da mensagem de requisição devem ser separados por uma 
linha contendo apenas a sequência de bytes <CR><LF>, onde <CR> e <LF> representam os carac- 


teres de retorno do cursor (Carriage Return) e mudança de linha (Line Feed), respectivamente. 


Após receber uma requisição, o servidor processa a requisição e retorna uma mensagem 

de resposta, que é composta por uma linha de status, algumas linhas de cabeçalho e o 
corpo. A linha de status contém a versão do protocolo HTTP, o código de processamento da 
requisição e uma mensagem textual. No exemplo de interação acima, o servidor adotou o 
protocolo HTTP/1.1 e a requisição foi processada com sucesso (200). Nas respostas, também 
existem diversos tipos de linhas de cabeçalho. Novamente, o exemplo ilustra apenas alguns 


tipos de linhas de cabeçalho. 


O cabeçalho Connection informa ao cliente se o servidor vai fechar ou não a conexão após 

o envio da resposta. Neste exemplo, o servidor fecha a conexão (close). O cabeçalho Date 
indica a hora e a data em que a resposta foi enviada pelo servidor. Por sua vez, o cabeçalho 
Last-Modified indica a data de criação ou modificação do objeto no servidor. Esta informação 
é usada pelo cliente para manter a cache local atualizada. O cabeçalho Server identifica o 
tipo do servidor que está gerando a resposta. Este exemplo foi realizado usando o servidor 
Apache/1.3.0. Os cabeçalhos Content Length e Content-Type indicam o tamanho em bytes do 
corpo da mensagem de resposta e o tipo de objeto que está sendo enviado. Estas informa- 


ções permitem ao cliente tratar adequadamente o objeto recebido. 


Na mensagem de resposta, após as linhas de cabeçalho, o corpo da mensagem contém o objeto 
solicitado na requisição. As linhas do cabeçalho e o corpo da mensagem de resposta também 


devem ser separados por uma linha contendo apenas a sequência de bytes <CR><LF>. 


Serviço de Acesso Remoto Seguro 


O serviço de acesso remoto seguro (SSH - Secure Shell) provê comunicação segura para aplica- 
ções de terminal remoto, transferência de arquivos e execução remota de comandos. Em sis- 
temas Linux, o serviço SSH tem funcionalidades semelhantes àquelas providas pelos comandos 
rlogin (remote login), rcp (remote copy) e rsh (remote shell). Entretanto, no SSH, os dados trans- 
mitidos são automática e transparentemente cifrados, assegurando autenticidade, privacidade 
e integridade. Ou seja, o SSH garante que as entidades comunicantes são autênticas e assegura 


que os dados enviados não são lidos ou modificados por outras entidades. 


Componentes 


Como mostrado da Figura 10.5, o serviço SSH adota a arquitetura cliente-servidor. Um ser- 
vidor SSH é um programa, tipicamente instalado e executado pelo administrador, que aceita 
ou rejeita requisições de conexão dos clientes SSH, provendo autenticação, privacidade e inte- 
gridade. Em sistemas Linux, a implementação do servidor SSH mais adotada é o servidor sshd. 
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Por outro lado, um cliente SSH é um programa tipicamente executado pelo usuário em 
estações remotas, que envia requisições ao servidor SSH para abrir uma sessão de terminal 
remoto, transferir arquivos ou executar comandos. Em sistemas Linux, os clientes SSH são 


implementados pelos programas ssh e scp. 


O serviço SSH é suportado pelo protocolo SSH, que define um canal seguro de comunicação 
entre o cliente e o servidor. O protocolo SSH utiliza a porta TCP 22. Existem duas versões 
incompatíveis do protocolo: SSH-1 e SSH-2. Embora o SSH-2 seja melhor e mais seguro, o 
SSH-1 ainda é a versão mais utilizada, pois o SSH-2 foi inicialmente proposto como uma 
solução comercial. Atualmente, um grupo de trabalho do Internet Engineering Task Force 


(IETF) está concentrando esforços para padronizar o SSH-2. 


No SSH, uma sessão representa uma conexão segura entre um cliente e um servidor. Todos 
os acessos ao serviço SSH envolvem duas autenticações: o cliente verifica a identidade do 
servidor (autenticação do servidor), e o servidor verifica a identidade do usuário que está 
requisitando o acesso (autenticação do usuário). A sessão SSH inicia depois que o cliente 


autentica o usuário no servidor e finaliza quando a conexão é fechada. 


O serviço SSH manipula duas chaves assimétricas (chave da estação e chave do servidor) e 
uma chave simétrica (chave de sessão). Cada chave assimétrica é composta pelo par: chave 
privada e chave pública. A chave simétrica possui uma única chave. Estas chaves são usadas 


pelos algoritmos de criptografia. 


A chave da estação (host key) é uma chave assimétrica usada pelo servidor SSH como prova 
da identidade da estação onde ele é executado. A chave da estação deve ser armazenada 


localmente na estação onde o servidor SSH é executado. 


A chave do servidor (server key) é uma chave assimétrica que é usada pelo servidor SSH para 
proteger a chave de sessão (descrita posteriormente). A chave do servidor é temporária, 
pois ela é recriada pelo servidor SSH em intervalos regulares (por default, a cada hora). 

A chave do servidor nunca é armazenada em memória secundária. Além disso, a chave 


privada do servidor nunca é transmitida em uma conexão. 


A chave de sessão é uma chave simétrica usada para cifrar a comunicação entre um cliente 
e um servidor SSH. A chave de sessão é gerada durante o procedimento de estabelecimento 
da sessão e destruída quando a sessão é finalizada. A chave de sessão é compartilhada 
entre o cliente e o servidor SSH. O protocolo SSH-1 usa uma única chave de sessão. 

No entanto, o protocolo SSH-2 possui várias chaves de sessão. Por exemplo, existem duas 
chaves de sessão que são usadas para cifrar a comunicação em cada direção: cliente-ser- 
vidor e servidor-cliente. 


Para realizar a autenticação dos vários servidores, o cliente mantém uma base de dados que 
armazena as chaves públicas das estações conhecidas. Quando um cliente e um servidor 
SSH estabelecem uma conexão, o cliente autentica o servidor usando as informações con- 
tidas nesta base de dados. Sempre que o cliente estabelece uma sessão com um novo ser- 
vidor, o cliente armazena a identificação do servidor e a respectiva chave pública da estação. 
Cada vez que o cliente se conecta ao servidor, o cliente verifica a identidade do servidor 


usando esta chave pública. 


Modelo de interação 


Para estabelecer uma sessão, o cliente e o servidor SSH trocam informações para negociar 


a chave de sessão e definir os algoritmos de criptografia e autenticação a serem adotados. 
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Além disso, durante o estabelecimento de uma sessão, o cliente e o servidor se autenticam 
mutuamente. A Figura 10.6 apresenta um exemplo de estabelecimento de sessão, onde as 


principais informações trocadas entre o cliente e o servidor podem ser identificadas. 


Cliente SSH Servidor SSH 


SSH-1.99-OpenSSH_2.2.0 
SSH-1.5-1.2.30 


















Chave Pública da Estação 
Chave Pública do Servidor 
Sequência de Verificação 

Lista de Algoritmos de Criptografia 
Lista de Algoritmos de Autenticação 






Algoritmo de Criptografia Selecionado 
Sequência de Verificação 
Chave de Sessão Cifrada 







Inicialmente, o cliente estabelece uma conexão na porta TCP 22 do servidor. Imediatamente 





Figura 10.6 
Estabelecimento de 
uma sessão SSH. 





após o estabelecimento da conexão, o cliente e o servidor enviam a identificação da versão do 
protocolo SSH suportado. Opcionalmente, o cliente e o servidor podem acrescentar a versão 
da implementação. Neste exemplo, cliente e servidor suportam a versão SSH-1, identificada 
pelos termos SSH1.51.2.30 e SSH1.990penSSH 2.2.0. Os termos 1.2.30 e OpenSSH 2.2.0 iden- 


tificam a versão da implementação do cliente e do servidor, respectivamente. 


Se o cliente e o servidor detectam que suas versões são compatíveis, o procedimento de 


estabelecimento da sessão prossegue. Caso contrário, a conexão é imediatamente fechada. 


Após negociar a versão do protocolo, o cliente e o servidor passam a se comunicar usando 
um protocolo de pacotes sobre a conexão TCP. Neste protocolo, cada pacote contém 
diversos campos, entre eles: um código que identifica o tipo de pacote (1 byte), os dados do 


pacote, e um campo de verificação de integridade (4 bytes). 


Neste momento, o servidor identifica-se para o cliente e provê alguns parâmetros da sessão. 
O servidor envia as seguintes informações para o cliente: a chave pública da estação, a 
chave pública do servidor, a sequência de verificação (check bytes), a lista de algoritmos de 
criptografia suportados pelo servidor, e a lista de algoritmos de autenticação suportados 
pelo servidor. A sequência de verificação protege o serviço de alguns tipos de ataques. 

O cliente deve devolver a mesma sequência de verificação na próxima mensagem enviada 


ao servidor. Caso contrário, o servidor rejeita a mensagem do cliente. 


Vale ressaltar que estas informações ainda não são cifradas. No entanto, todas as 
Q informações podem ser publicamente conhecidas, não apresentando qualquer risco 


à segurança do serviço. 


Neste ponto, o cliente e o servidor computam um identificador de sessão de 128 bits, que 

é usado em algumas operações subsequentes do protocolo para identificar de forma única 
a sessão SSH. Este identificador é calculado usando a chave pública da estação, a chave 
pública do servidor e a sequência de verificação. Como o cliente e o servidor possuem estas 


informações, ambos computam um mesmo identificador. 


Em seguida, consultando a base de dados de estações conhecidas, o cliente verifica se a 
estação do servidor já é conhecida. Se a estação do servidor está na base de dados e a 
chave pública armazenada é igual àquela recebida, o cliente aceita a sessão. Caso contrário, 
existem duas outras possibilidades: a estação do servidor não está presente na base de 
dados; ou a estação do servidor está presente, mas a chave pública armazenada não é igual 
aquela recebida. Em ambos os casos, o cliente solicita o auxílio do usuário, perguntando se 
ele aceita ou rejeita a chave pública recebida. Se o usuário aceita a chave pública da estação, 
o cliente estabelece a sessão e armazena a nova chave na base de dados de estações conhe- 


cidas. Caso contrário, o cliente rejeita a sessão e fecha a conexão. 


Após aceitar o estabelecimento da sessão, o cliente gera uma chave de sessão, que será 
usada posteriormente para cifrar e decifrar as mensagens enviadas, tanto pelo cliente, 
quanto pelo servidor. O cliente deve enviar a chave de sessão para o servidor de forma 
segura. No entanto, neste instante, a comunicação entre o cliente e o servidor ainda não 

é segura. Para tal, o cliente cifra a chave de sessão com a chave pública da estação, e, em 
seguida, cifra novamente com a chave pública do servidor. A criptografia dupla assegura que 
somente o servidor pode recuperar a chave de sessão. 


Após cifrar a chave de sessão, o cliente envia a chave de sessão cifrada para o servidor, 
juntamente com a sequência de verificação e uma indicação do algoritmo de criptografia 
selecionado. Agora, o cliente aguarda uma mensagem de confirmação do servidor, que, 
como todas as demais mensagens, já deve ser cifrada com a chave de sessão. 


A mensagem de confirmação cifrada realiza a autenticação do servidor, pois somente ele 
pode decifrar a chave de sessão, uma vez que ela foi cifrada com a chave pública da estação 
e a chave pública do servidor. Se a mensagem de confirmação cifrada não é recebida, o 
cliente fecha a conexão. O protocolo SSH-1 não é específico neste ponto, mas a segunda 
versão especifica a necessidade desta mensagem de confirmação, quando a autenticação 
do servidor é realizada de forma implícita através da chave de sessão. Neste momento, 

a comunicação segura pode ser iniciada, pois o cliente e o servidor conhecem a chave de 
sessão. Desta forma, ambos começam a cifrar todos os dados da sessão, usando o algo- 


ritmo de criptografia selecionado e a chave de sessão. 


Antes de permitir qualquer tipo de acesso, o servidor deve, primeiramente, autenticar o usuário 
do cliente. O protocolo SSH suporta vários métodos de autenticação do usuário, por exemplo, 
usando senhas e chaves públicas. O cliente tenta os métodos suportados pelo servidor, infor- 


mados na lista de algoritmos de autenticação, até que um tenha sucesso ou todos falhem. 


Para ilustrar a autenticação do usuário, vamos descrever a autenticação baseada em 
senhas. Nesta modalidade, o usuário fornece sua identificação e senha ao cliente SSH. 
Usando a conexão segura, o cliente transmite a identificação e a senha para o servidor. 

O servidor autentica a senha para aquele usuário e, caso válida, permite o acesso remoto 
seguro. Geralmente, o servidor SSH verifica a validade da senha usando o mecanismo de 


autenticação do próprio sistema operacional. 
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Opções de captura 





= Roteiro de Atividades 10 


Atividade 10.1 - Captura de pacotes UDP do serviço DNS 


1. Vamos ativar o Wireshark, como fizemos anteriormente, só que desta vez para configurar 
um filtro de captura. Na tela inicial do Wireshark, em vez de selecionar o botão “Start”, 


selecione o botão “Options” na interface de rede local. 


Teremos então a tela a seguir. Na janela “Capture Filter:”, digite a palavra udp, conforme 
mostrado na figura 10.7. Observe que a janela de filtro de captura fica com o fundo verde 


quando a sintaxe do comando está correta e vermelha quando não está correta. 





rCapture 
Interface: [Local [=| | Microsoft: \Device\NPF_{DE17AD59-121 C-4923-A580-FCBDFBA26E] | 
IP address: fe80::d0ce:722c:edal:17d6, 192.168.100.103 


Link-layer header type: Ethernet [x] | Wireless Settings | 


Capture packets in promiscuous mode | 























Remote Settings | 





Capture packets in pcap-ng format 
Limit each packet to 655235 Ë bytes iN =| megabyte(s) 


E [=] (Gone 


Figura 10.7 Em seguida clique em “Start” para iniciar a captura, porém, somente serão capturados os 























pacotes que contenham o protocolo UDP. Os demais pacotes IP serão descartados. 
de pacotes do 


Wireshark. ; go ; 
2. Abra uma janela de prompt de comando e digite os seguintes comandos: 


ping www.google.com.br 
ping www.esr.rnp.br 


Aguarde até que todas as operações tenham sido concluídas, volte para a janela do 
Wireshark (que ficou aberta) e só então termine a captura de pacotes clicando no quarto 


ícone da esquerda para a direita da barra de ferramentas (Stop the running live capture). 


A janela de captura do Wireshark deve ser semelhante à mostrada na figura 10.8. Podem 
surgir mais alguns pacotes eventualmente, dependendo da rede local do laboratório, mas 


Figura 10.8 somente os mostrados na figura são importantes. 
Captura de 
pacotes UDP. Esta janela se refere ao arquivo de captura: “Sessao10 Captural.pcap”. 


No. Time Source Destination Protocol Length Info 
1 0.000000 192.168.100.103 200.130.77.69 DNS 77 Standard query A www. google. com. br 
2 0.003075 200.130.77.69 192.168.100.103 DNS 265 Standard query response CNAME www-cctld.1.gor 
3 26.793504 192.168.100.103 200.130.77.69 DNS 74 Standard query A ww. esr.rnp. br 
4 26.918075 200.130.77.69 192. 168. 100. 103 DNS 299 standard query response A 200.130.35.73 


m 


4 Frame 1: 77 bytes on wire (616 bits), 77 bytes captured (616 bits) 

Ethernet II, Src: HonHaiPr 60:a2:la (00:24:2c:60:a2:1a), Dst: Cisco-Li_c8:b5:2a (00:18:39:c8:b5:2a) 
Internet Protocol Version 4, Src: 192.168.100.103 (192.168.100.103), Dst: 200.130.77.69 (200.130.77.69) 
User Datagram Protocol, Src Port: 59840 (59840), Dst Port: domain (53) 

5 Domain Name System (query) 


= E) E) E E 
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3. Nesta figura o pacote 1 está selecionado na primeira janela e na segunda janela 
estão os protocolos que foram utilizados. Note que aparecem, de cima para baixo, as 


seguintes camadas: 

3.1. Camada física (Frame 1) 

3.2. Camada de enlace (Ethernet II) 

3.3. Camada de rede (Internet Protocol Version 4) 
3.4. Camada de transporte (User Datagram Protocol) 
3.5. Camada de aplicação (Domain Name System) 


4. Selecionando a camada de transporte na segunda janela, teremos a janela mostrada na 
figura 10.9. 


Frame 1: 77 bytes on wire (616 bits), 77 bytes captured (616 bits) 
Ethernet II, Src: HonHaiPr_60:a2:1a (00:24:2c:60:a2:1a), Dst: Cisco-Li_c8:b5:2a (00:18:39:c8:b5:2a) 
Internet Protocol version 4, Src: 192.168.100.103 (192.168.100.103), Dst: 200.130.77.69 (200.130.77.69) 
Suurce purl: 59840 (59840) 
Destination port: domain (53) 
Length: 43 
= Checksum: 0x4dii [validation disabled] 
= Domain Name System (query) 


=) E) E 


0000 00 18 39 c8 b5 2a 00 24 2c 60 a2 la 08 00 45 00 ..9..%.$ ,'....E. 

0010 00 3f Oc d9 00 00 80 11 f2 fd cO a8 64 67 c8 82 .2...... ....dg.. 

0020 4d 45 QETE GET Va YF UI OU U0 Ul  MERRRERMA...... 

0030 00 00 00 00 00 00 03 77 77 77 06 67 6f 6f 67 6c ....... w ww. goog] 

0040 65 03 63 6f 6d 02 62 72 00 00 01 00 01 e.com.br ..... 

Observe que na terceira janela, onde estão representados os dados no formato hexadecimal, Figura 10.9 


Detalhe do pacote 


estão destacados apenas os dados do cabeçalho UDP (8 bytes). Os dados importantes são: 
UDP número 1. 


o Porta de origem: 59840 
o Porta de destino: 53 


Essa porta é a “porta bem conhecida” utilizada pelo servidor DNS e se trata de uma consulta 
ao servidor DNS para resolução do nome www.google.com.br, que foi o nome usado no 


comando ping na janela DOS. 


5. Nalinha do protocolo IP (camada de rede), podemos ver que a estação de origem tem o 
IP: 192.168.100.103 e o servidor DNS consultado tem o IP: 200.130.77.69. 


6. O próximo pacote (número 2) é a resposta do servidor DNS, destinado à estação que 


enviou a solicitação no pacote 1. Essa resposta contém o endereço IP do nome solicitado. 


Qual é o endereço IP do nome solicitado? 





Os pacotes 3 e 4 são semelhantes, referentes à resolução do nome: www.esr.rnp.br. 





Qual o endereço IP do nome solicitado? 





Nos dois casos, foram usadas as mesmas portas? Explique. 























Atividade 10.2 — Requisições iterativas e recursivas 


O serviço de nomes possui dois componentes. O resolver envia requisições aos servidores de 
nomes, que, por sua vez, processam essas requisições e devolvem as respectivas respostas. 
Considerando o modelo cliente-servidor, qual o papel do resolver e do servidor de nomes em 


requisições iterativas e recursivas? 














Atividade 10.3 — Servidores raiz 


Todo servidor de nomes deve conhecer os endereços IP dos servidores do domínio raiz. 
Para facilitar a atualização da lista de servidores raiz, essa informação é disponibilizada na 
internet. No entanto, não existe um mecanismo para informar aos administradores sobre 
atualizações nas informações dos servidores raiz. Dessa forma, não é incomum encontrar 
servidores que possuem endereços incorretos de alguns servidores raiz. Como o serviço de 


nomes pode continuar funcionando mesmo com a existência dessas inconsistências? 











Atividade 10.4 — Consultas DNS 


O comando host é um utilitário para realizar consultas ao serviço de nomes. O exemplo 
listado a seguir mostra a sintaxe do comando. A opção -t indica o tipo de registro de recurso 
a ser consultado, por exemplo: A, PTR, CNAME, HINFO, MX e NS. O primeiro parâmetro 
(www.esr.rnp.br) é o nome a ser resolvido, podendo ser um nome de domínio, um nome de 
estação ou um endereço IP. O segundo parâmetro (/ua.na-df.rnp.br) é o nome do servidor 
de nomes a ser consultado. Se o servidor de nomes não é informado, o comando host usa 

o servidor de nomes default, configurado no arquivo /etc/resolv.conf (Linux) ou na configu- 


ração da interface de rede no campo DNS (Windows). 

core@ubuntu:~$ host -t A www.esr.rnp.br lua.na-df.rnp.br 
Using domain Server: 

Name: lua.na-df.rnp.br 

Address: 200.130.77.69#53 

Aliases: 

www.esr.rnp.br has address 200.130.35.73 


No exemplo, uma requisição tipo A é enviada ao servidor de nomes /ua.na-df.rnp.br para 


mapear o nome da estação www.esr.rnp.br para seu respectivo endereço IP 200.130.35.73. 


Se a opção -t não é usada e o primeiro parâmetro é um nome de estação, por default, o 
comando host realiza uma consulta do tipo de registro A, mapeando o nome da estação para 
seu respectivo endereço IP. No entanto, se a opção -t não é usada e o primeiro parâmetro 

é um endereço IP, por default, o comando host realiza uma consulta do tipo de registro PTR, 


mapeando o endereço IP para seu respectivo nome de estação. 
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Este exemplo foi executado na máquina virtual CORE, usando o console “Terminal”, cujo ícone 


está na área de trabalho do Ubuntu. Para as próximas atividades, use o mesmo console. 


1. Usando o mesmo servidor de nomes, identifique o endereço IP da estação www.rnp.br. 








2. Usando o mesmo servidor de nomes, descubra o nome da estação cujo endereço IP é 
200.130.25.1. 








3. Usando o mesmo servidor de nomes, encontre os servidores de nomes do domínio rnp.br. 








4. Usando o mesmo servidor de nomes, identifique os servidores de correio eletrônico do 
domínio rnp.br. 





Atividade 10.5 - Serviço SSH 
Instalação do serviço SSH 


1. Digite o seguinte comando no terminal do Linux: 


# sudo apt-get install ssh 
2. Informe a senha do usuário: core. 
3. Aguarde até que a instalação esteja terminada. 
Criar uma conexão segura ao servidor remoto 
1. Digite o seguinte comando no terminal do Linux: 
# ssh <ip_do_servidor_remoto> 


2. Confirme a autenticidade da chave apresentada: 


Are you sure you want to continue connecting (yes/no)? yes 


(D A partir de agora não é mais solicitada a confirmação, somente a senha do usuário. 


3. Confirme se está no computador desejado com o seguinte comando: 


# hostname 


Incluir um novo usuário na máquina remota 


1. Digite o seguinte comando no terminal do Linux: 


# adduser <nome do usuário> 


Figura 10.10 
Pacotes capturados 
com destaque para 

o pacote 7. 


No 


JF 





Time 
1 0. 000000 
2 8.647000 
3 8. 697077 
4 8.697200 
5 8.703727 
G 8.703905 
7 8.874007 
8. 875000 
8.875535 


8 
9 


Frame 7: 105 
Ethernet II, 


2. Digite as informações solicitadas. Não se esqueça de criar uma senha e confirmá-la. 


3. Para fechar a conexão SSH: 


# exit 


Transferir um arquivo remoto para o host local e vice-versa 


Suponha o host local com endereço 192.168.100.123 e o host remoto (servidor SSH) com 


endereço 192.168.100.127. Sequência de comandos: 
# ssh 192.168.100.127 (estabelece a conexão SSH com o servidor remoto) 
# scp Rede Atividade6 2.imn lobato@192.168.100.123:/home/lobato 


The authenticity of host ‘192.168.100.123 (192.168.100.123)’ can’t be 
established. 


RSA key fingerprint is 43:44:f2:4d:78:20:60:d7:31:d3:26:b1:20:ee:dc:f3. 
Are you sure you want to continue connecting (yes/no)? yes 


Warning: Permanently added ‘192.168.100.123’ (RSA) to the list of 
known hosts. 


lobato@192.168.100.123’s password: 
Rede_Atividade6_2.imn 100% 2866 2.8KB/s 00:00 
# 


A sequência de comandos acima mostra a transferência do arquivo “Rede Atividade6 2. 
imn” do host remoto para o host local. 


Análise dos pacotes SSH 


Iniciando o Wireshark na interface de rede de um dos hosts envolvidos na transferência 
acima podemos ver os pacotes trocados entre eles, que foram capturados no arquivo 


“Sessao10_Captura2.cap”. 


A Figura 10.10 mostra os primeiros pacotes capturados, com destaque para o pacote 7. 


Source Destination Protocol Length Info 

Apple 42:9c:5b Broadcast ARP 42 who has 192.168.100.1? Tell 192.168.100.106 
192.168.100.123 192.168.100.127 TCP 74 51419 > ssh [SYN] Seq-0 win-5840 Len-0 M55-1460 SACK PERM-1 
Cadmusco_00:d1:5iBroadcast ARP 60 Who has 192.168.100.123? Tell 192.168.100.12 
HonHalpr_60:a2:licadmusco_00:d1:58 ARP 42 192.168.100.123 is at 00:24:2c:60:a2:la 

192.168.100.127 192.168.100.123 TCP 74 ssh > 51419 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 mss=1460 
192.168.100.123 192.168.100.127 TCP GG 51419 > ssh [ACK] Seq=1 Ack=1 win=5888 Len=0 Tsval=2390074 
192.168.100.127 192.168.100.123 SStiv2 105 Server Protocol: SSI-2.0-Openssii_5.8p1 Debian-lubuntu3\r 
192.168.100.123 192.168.100.127 Tce 66 51419 > ssh [ACK] Seqel Ack=40 win=5888 Len=0 TSval-2390117 
192.168.100.123 192.108.100.127 SSHV2 105 Client Protocol: SSH-2.0-OpenSSH_>. 3pl Debian-3ubuntu/\r 


qm 


bytes on wire (840 bits), 105 bytes captured (840 bits) 
Src: Cadmusco 00:d1:58 (08:00:27:00:d1:58), Dst: HoniaiPr. 60:a2:1a (00:24:2c:60:aZ:la) 


Internet Protocol Version 4, Src: 192.168.100.127 (192.168.100.127), Dst: 192.168.100.123 (192.168.100.123) 
Transmission Control protocol, src Port: ssh (22), Dst Port: 51419 (51419), Seg: 1, Ack: 1, Len: 39 


= SSH Protocol 


Protocol: SSH-?.0-OpenSSH_5.8p1 Nebian-1ubuntu3\r\n 


Observações importantes sobre a Figura 10.10: 


a Os pacotes 3 e 4 do protocolo ARP são para obter o endereço MAC da estação 
192.168.100.123 e a pergunta foi feita pela estação 192.168.100.127. 


a Os pacotes 2, 5 e 6 estabelecem uma conexão TCP entre os dois hosts. 


o O pacote 7 é do protocolo SSH versão 2.0. 
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A Figura 10.11 mostra alguns pacotes criptografados pelo SSH. 








conexão, com informações sobre a quantidade de octetos transmitidos/recebidos. 


Os demais pacotes são do protocolo SSH e estão criptografados. 


Backup de uma estação remota com SSH 


No. Time Source Destination Protocol Length Info 
35 15.996173 192.168.100.127 192.168.100.123 sstivz 146 Encrypted response packet len-80 
36 15.996539 192.168.100.123 192.168.100.127 SSHv2 114 Encrypted request packet Ter=48 
37 16.036853 192.168.100.127 192.168.100.123 TCP 66 ssh > 51419 [|ACK] Seq=2040 Ack=1608 win=22400 
38 16.146326 192.168.100.127 192.168.100.123 SSHv2 146 Encrypted response packet len=80 
39 16.147651 192.168.100.123 192.168.100.127 SSHv2 114 Encrypted request packet len=48 
40 16.150043 192.168.100.127 192.168.100.123 TCP 66 ssh > 51419 [acK] Seq=2120 Ack=1656 win=22400 
41 16.184083 192.168.100.127 192.168.100.123 ssHv2 1514 Encrypted response packet len-1448 
42 16.184360 192.168.100.127 192.168.100.123 SSHv2 1514 Encrypted response packet len=1448 
43 16.184445 192.168.100.123 192.168.100.127 ICP 66 51419 > ssh [ACK] segq=1656 ack=5016 win=16768 
Na Figura 10.11, os pacotes 37, 40 e 43 são do protocolo TCP e destinam-se ao controle da Figura 10.11 
Pacotes 


Um administrador de rede necessita criar um backup de uma estação de trabalho remota 


utilizando SSH. Como deve proceder? 


1. Acesse o computador remoto através do SSH: 


# ssh <ip remoto> 


2. Utilize o comando tar para fazer um backup da estação remota: 


# tar -cvzf /backup.tar.gz --exclude=/proc --exclude=/lost+found 


--exclude=/backup.tar.gz -exclude=/mnt -exclude=/sys / 


3. Volte para o terminal local: 


# exit 


4. Copie o arquivo compactado da máquina remota para a máquina local: 


# scp user@<ip remoto>:/backup.tar.gz 


criptografados. 
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